Re: Optimizing Static Variable Layout


Betov wrote:
> "f0dder" <spamtrap@xxxxxxxxxx> écrivait news:426ec27d$0$163
> $edfadb0f@xxxxxxxxxxxxxxxxxxxx:
>
> > Considering the kind of data used in most applications, I don't
> > think the savings you can achieve will justify the complexity
> > of implementing this feature - and it might come as a surprise
> > to people expecting their variable declarations to be linear in
> > memory.
>
> Not at all. This is a feature that is implemented
> in RosAsm since day one, and this is no problem at
> all, if correctly implemented, that is on a Block
> Base, and under full control of the Programmer.

It *does* come as a surprise to people who want to control the
placement of variables in RosAsm. If someone types:

[a:B$ 1]
[b:B$ 2]

They probably wouldn't expect these two declarations to consume eight
bytes in their static data's address space. Forcing the user to specify
byte alignment on byte declarations is hardly intuitive; as such,
f0dder is right - it just might come as a surprise.

As for the first issue f0dder raises, the complexity of the algorithm,
what RosAsm is doing is *not* what RosAsm is doing. RosAsm simply
injects extra bytes between each declaration block to force the
alignment to be dword-aligned. The proposal I'm making is to rearrange
the declarations in memory so that the extra padding bytes (needed for
values the programmer *explicitly* requests alignment for) might be
used for actual variables. For example, consider the following
declaration sections:

static(2)
w:word;

static(4)
d:dword;

static
b:byte;
c:byte;

If the assembler simply processed these declarations in the order it
encountered them, you'd probably expect the following memory layout:

0: w
2: two bytes of padding for alignment
4: d
8: b
9: c

However, as the declaration sections (beginning with "static" are all
independent (as the HLA documentation claims, for example), there is no
reason the assembler couldn't rearrange these declarations thusly:

0: w
2: b
3: c
4: d

Thus saving two bytes. That's what this "idea" is all about. Trying to
reusing those "padding" bytes wherever possible to hold actual data.

However, as f0dder correctly points out, this must be done *carefully*
because you don't want to violate intuition. Injecting extra padding
bytes, when they are not explicitly requested, is such a violation.
Cheers,
Randy Hyde

.

Relevant Pages

  • The Case Against RosAsm (#9)
    ... RosAsm Doesn't Do Structures ... Some bad Assemblers have a "STRUCT" KeyWord performing hidden Declarations ... What is effectively done by the Assembler would be expressed, ... the right Edit Control gives you the Structure Equates translation. ...
    (alt.lang.asm)
  • Re: RosAsm injects extra bytes into your data
    ... why not rearrange all the declarations to ... >> the wasted space while maintaining the alignment the user requests. ... If they do, then does RosAsm build ...
    (alt.lang.asm)
  • Re: Structures in Assembly Language
    ... not a Language that _HIDES_. ... and the Equates DECLARATIONS, if you want Equates, Data ... guy who says 20 lines downward: "I don't use RosAsm, ... C-Like Structures implemented, it would not be an Assembler, ...
    (alt.lang.asm)
  • Re: Localized Parameter Directive?
    ... In fact there are 10 or 20 API declarations ... Neither will MASM, once you set up case sensitivity so that it thinks ... RosAsm doesn't really have a notion of local variables in a procedure ... treat Win32 symbols differently from other symbols and you have to use ...
    (alt.lang.asm)
  • Re: RosAsm injects extra bytes into your data
    ... > Betov wrote: ... > RosAsm, by default, automatically *injects* padding bytes everywhere. ... why not rearrange all the declarations to *minimize* ... for the Programmer. ...
    (alt.lang.asm)