Re: HLA Lib
- From: Charles Crayne <charles.crayne@xxxxxxxxxx>
- Date: Mon, 19 Mar 2007 21:58:06 -0700
On 19 Mar 2007 20:31:33 -0700
"randyhyde@xxxxxxxxxxxxx" <randyhyde@xxxxxxxxxxxxx> wrote:
It's a real shame to watch a programmer do things like use a 1-
byte SCASD instruction to add 4 to EDI (to save a byte or two) and
then have ten times that amount wasted by a memory allocation call.
Quite so, which is why initial allocations should be (under the
programmer's control) large enough for the string buffer to expand and
contract multiple times without triggering a reallocation.
Personally, I'm a bit concerned about the nine bytes of overhead that
HLA strings already consume.
Rather than being concerned, I would say that your code is a model of
conciseness. Even in 32-bit code, it is difficult to pack all the
string management information into only nine bytes. I have always
considered a 16-bit maximum length field, and a 16-bit current length
field to be an absolute minimum, with a 32-bit chain pointer as a
useful addition. And in my multitasking code, another 32-bit field is
required for the tcb address of the owning task.
Then again, memory size really doesn't matter any more. So maybe all
my debating is pointless. :-)
Even on 32-bit systems, virtual memory size doesn't matter much, and as
the x86_64 systems become standard, it will matter even less. What does
matter is working set, and -- to a much lesser extent -- cache line
management. HLL programmers, of course, leave all that to the compiler,
but assembly language programmers should learn to pay attention to
these issues.
-- Chuck
.
- Follow-Ups:
- Re: HLA Lib
- From: vid512@xxxxxxxxx
- Re: HLA Lib
- References:
- HLA Lib
- From: vid512@xxxxxxxxx
- Re: HLA Lib
- From: randyhyde@xxxxxxxxxxxxx
- Re: HLA Lib
- From: vid512@xxxxxxxxx
- Re: HLA Lib
- From: randyhyde@xxxxxxxxxxxxx
- Re: HLA Lib
- From: vid512@xxxxxxxxx
- Re: HLA Lib
- From: randyhyde@xxxxxxxxxxxxx
- Re: HLA Lib
- From: vid512@xxxxxxxxx
- Re: HLA Lib
- From: randyhyde@xxxxxxxxxxxxx
- Re: HLA Lib
- From: vid512@xxxxxxxxx
- Re: HLA Lib
- From: randyhyde@xxxxxxxxxxxxx
- HLA Lib
- Prev by Date: Re: HLA Lib
- Next by Date: Re: my assembler is better than your assembler
- Previous by thread: Re: HLA Lib
- Next by thread: Re: HLA Lib
- Index(es):
Relevant Pages
|