Re: HLA Lib

allright, i will do some comparison to FASMLIB speed. (and maybe steal
some faster HLAlib algos) We'll see, algos in FASMLIB are simple (not
optimized) and straightforward.

Don't steal mine at this point, grab Terje's. It's a little faster on
most processors except the P4 (which has a broken multiply
instruction).

done it. Tests proved you were right. However using such optimized
algorithm becomes problem in case of FASMLIB functions, which is
designed to do provide much more functionality (buffer overflow
testing, in case of buffer overflow the valid portion of buffer is
still filled, etc...) It would be real pain to implement it in
FASMLIB.

Aw, that's a myth. All modern OSes guarantee that they clean this sort
of stuff up. You don't want to get in the *habit* of not freeing up
resources and so on, but when done *on purpose*, as is the case here,
there's nothing wrong with it. The OS behavior is well-documented.
Where exactly is unmapping virtual memory quaranteed?

I think 64 bytes is too much. 16 bytes is probably about right (so
that you're guaranteed 16-byte alignment for certain SSE operands).
OTOH, HLA's memory manager actually does align to 16 bytes + 8, so
getting 16-byte alignment is pretty easy -- just allocate 8 extra
bytes and bump the returned address up by 8.

Still i think that 32bytes wouldn't cost you lot of memory, and will
reduce need to resize blocks for 98% string operations. With 16bytes
you are probably going to hit few more.

That would need some testing.

The problem with a large granularity on the allocation is that typical
programs make a *lot* of small memory requests. In particular, the
average string length you'll find in a program is quite small.

This is true for C++ and higher languges, and some C apps, but IMO not
for typical assembly programs.

Another
example is an assembler. Consider FASM, for example. It makes *lots*
of small memory requests.

It would be very ugly not to use custom allocation for array of static-
sized objects, if memory size matters. :)

I have some thoughts about support for lists and vectors...

BTW, reallocations are one area where the HLA memory manager *isn't*
all that great. To reduce fragmentation, the HLA memory manager
allocates blocks from the end of the heap on down. This makes it
unlikely that reallocation will simply consist of extending the size
of the current block. OTOH, it *does* make the first-fit algorithm
that HLA uses run incredibly fast because it almost always finds a
block large enough just below the active end of the heap.

can't you just search from last block to first? that would have both
advantages, wouldn't it?

Actually, I *do* mention it in the documentation. I've just not gotten
around to *posting* that documentation yet (that will come out with
HLA stdlib v2.1, which I'll get back to work on after I get around to
finishing HLA v1.90).

Still i dislike that kind of behvior. Reminds me of oldschool unix
guys who need EOL at end of last line :))

I'm not sure I see the problem here. Unlike fileio, the stdin package
generally strips and ignores the end-of-line sequence. This is an
artifact of the buffering that stdin uses (versus the lack of
buffering in fileio). If a line does not contain an end-of-line
sequence, but butts right up against EOF, then the ReadLn function
will supply a phantom EOLN and the stdin functions will process that
last line properly. On the very next input operation, you *will* get
an EOF exception raised. The user's program never sees that phantom
newline; it exists solely for the correct operation of ReadLn.

Problem is if that function is used by anything else than readln.
Especially by some user function. For example in some "wc -l" type of
application...


.