Re: RosAsm Team is Still Making Excuses

Alex McDonald wrote:
> No, I don't understand the syntax or the semantics, otherwise I
> wouldn't ask. From your previous post and this confusing reply, it's
> not clear to me if a line break causes a dword alignment or not. An
> overview of the automatic alignment and when it does and does not
> happen would be edifying. Oh, and be polite. It costs nothing and may
> win you friends.

A more than reasonable request...but, apparently, beyond the capabilities
of Rene, as he hasn't replied...seems he's not yet mastered "polite" and
you ask too much of him ;)...

For confirmation, I put the line in question into RosAsm:

[ Test: B$ 0 1 2 3 4 5
6 7 8 ]

....and then compiled it...then took a look at the data section with
OllyDbg, which reports:

00403000 00 01 02 03 04 05 06 07
00403008 08 00 00 00 00 00 00 00

Which basically means that, no, the newline does NOT effect things...the "6
7 8" declarations are still assumed to be bytes...RosAsm appears not to pay
attention to newlines in this context and continues the "byte size"
specifier onto the next line...

Interestingly, this even continues with new data declarations too...as this
small addition:

[ Test1: B$ 0 1 2 3 4 5
6 7 8
Test2: 9 10 11 12 ]

....produces:

00403000 00 01 02 03 04 05 06 07
00403008 08 09 0A 0B 0C 00 00 00

....which means RosAsm is also still continuing the "B$" specifier for the
new data declaration too...this _might_ be "problematic" in that RosAsm
"defaults" to using a DWORD size when the specifier is missing BUT, in this
case, as the previous data was byte sized then this "flows" on into the
next declaration...not that this is in anyway "wrong", of course...but it
might be confusing and perhaps the B_U_ASM manual should clarify this point
(because I see no mention of this in the manual)...

So, for the record, RosAsm does NOT force DWORD alignment on a newline...

I think what's happened is that there's been a misunderstanding...but
Rene's reluctance to clarify or reply politely has stupidly propogated a
"myth" about RosAsm here, which actually isn't true...he, of course, should
have - as you say - just clarified what is currently a bit confusing...as,
in fact, on this point, Rene has "nothing to hide"...

What I think _MIGHT_ have happened here is that wolfgang said:

> If you like to have a consecutive set of bytes, then just
> declare them within a line.
> [MyBytes: B$ 0 1 2 3 4 5]
> BU_ASM_Help says: 'a new line forces DW-alignment'.

....and the misunderstanding is that what wolfgang meant was a "new line" in
this context:

[ Test1: B$ 0 1 2 3 4 5 6 7 8 ]

[ Test2: 9 10 11 12 ]

....which produces:

00403000 00 01 02 03 04 05 06 07
00403008 08 00 00 00 09 00 00 00
00403010 0A 00 00 00 0B 00 00 00
00403018 0C 00 00 00 00 00 00 00

That is, there is DWORD alignment for each "data block" (e.g. in between
the square brackets :)...and I think wolfgang was, you know, casually
calling this a "new line" (as in: "starting a new declaration on a new
line")...

Problem is, if you like, Randy read "newline" (in the formal ASCII
character sense) when wolfgang said "new line" (in the informal "start a
new declaration on a separate line" sense)...and the very subtle difference
between the two readings has caused a mild misunderstanding that has
exploded into this thread...

In fact, it's like that infamous "punctuation misunderstanding" from
history, where a note was written where it had something like: "it would be
easy to kill, the king would make people happy"...which, with the comma,
meant one thing...but the reader read it as: "it would be easy to kill the
king" and took it as an order to assassinate the king (well, this was not
exactly what was written, as I don't remember the exact wording off the top
of my head...but this is the rough "gist" of what happened, as I remember
hearing it, anyway :)...

Oops! A case from history where that whole "eats, shoots and leaves"
punctuation thing _WAS_ actually a literal "matter of life and death"...so,
if anyone says punctuation is not important, then history begs to differ...

So, the space is important: Wolfgang said "new line" and not "newline", if
you know what I mean...also, he was being "informal" in just meaning "start
a new declaration on the next line", not "formal" in meaning "the CR / LF
ASCII characters force DWORD alignment"...

Nevertheless, there's no need to panic...the matter is, of course, easily
resolved by, well, just typing in the statements and seeing what happens...

More generally, by the way - as you did ask for a general explanation of
how it works - then RosAsm automatically provides DWORD alignment when you
open a new "data block" (that is, open up a new set of square brackets
:)...this _CAN_ be "overridden", though, using "[<" to open the data block:

[<Test: B$ 1 2 3 ]

(Note: For some odd reason, the line "[< Test2: 9 10 11 12 ]" produces the
error message "A number cannot be a symbolic name"...while "[<Test2: 9 10
11 12 ]" compiles properly...this is a strange thing and I'm not sure if
it's intentional that the space makes a difference to the
interpretation...I would "bug report" directly to Rene but, well, what are
the chances of being successful there? He'd refuse to fix it just because
it's me saying it or something silly like that...well, whatever...his bug,
his problem...I've mentioned it here and he can read this and fix it if he
likes...up to him...I don't really care :)...

....and, more generically, if you place a number after the "<" then you can
manually specify the alignment:

[<8 Test: B$ 1 2 3 ]

....which aligns to the 8 byte "QWORD" boundary...

[ I attempted to use "3" and "5" - not "powers of two" - to see if RosAsm
also catered for this...there is no complaint about using a
non-power-of-two as the alignment when assembling the code...but, in the
hex dump, it seems to simply _IGNORE_ it and "byte align" regardless (as if
you'd just put "[<" without any alignment value)...a shame...I actually
think that a tool should simply align to whatever value you provide,
whether it's a "power of two" or not...yeah, there probably is not much of
a useful reason to ever want a non-power-of-two for alignment...BUT, well,
what's the point of not allowing it? ]

When you use any string declaration, RosAsm automatically assumes "B$":

[ MyString: "Hello, there" 0 ]

BUT, interestingly, the "0" at the end there is a DWORD (which relates, I
presume, to the standard "default" that without an explicit size specifier,
RosAsm assumes "D$"...and the different "default" for character strings
simply doesn't effect this default when it reaches the number there at the
end...though, I'm just guessing there...but it makes sense :)...

So, you should put "B$" specifically there if you also wanted the "0" to be
a byte, as well...

And when you don't specify a size, RosAsm presumes DWORD:

[ Var: 36 ]

....which would be a DWORD in size and DWORD aligned...

This _IS_ complicated a little, though, by the fact that RosAsm's syntax
here seems "context sensitive"...that is, as noted above, if you put:

[ Test2: 9 10 11 12 ]

Then these would be DWORDs...BUT the following:

[ Test1: B$ 0 1 2 3 4 5
Test2: 9 10 11 12 ]

....are all BYTES (even though the second line there is the same as the
first line above)...this is because the "B$" specifier "flows" onto the
next declaration too...basically, the "B$" / "W$" / "D$" appear to be
effectively "sticky" modifiers (they change the size from then on until
another size specifier is found or we hit the end of the "data block"
:)...so, the same line can actually have different sizes, depending on what
the lines before it are (in the same "data block", anyway...different data
blocks and this isn't an issue)...

[ Though this is a bit unusual in a syntax, it might, of course, be quite
intentional in Rene's design and is just a case of "be aware that it does
this"...rather than necessarily being "wrong syntax"...well, this kind of
thing is all a "matter of opinion" and "taste", after all...so, yeah, I'm
just noting this to make people "aware" that it does it...I'll reserve
casting any "judgements" on whether it's a "good idea" or not for some
other post... ]

Well, it's not exactly "exhaustive" there of all RosAsm's
capabilities...just the "basics"...but it should perhaps answer your
question there about what RosAsm does and doesn't do with the alignment and
data sizes...

Beth :)


.

Relevant Pages

  • Re: RosAsm Team is Still Making Excuses
    ... mov(0, (type dword total)); ... Apparently not on the PIII on which I ran this test. ... > | RosAsm does this - the user base doesn't seem to know any better. ... It's a crazy idea to waste space between the declarations if there is ...
    (alt.lang.asm)
  • RosAsm injects extra bytes into your data
    ... If this is an example of how much better off beginners are with RosAsm ... declare *all* your variables in the same declaration section. ... The assembler is going to have to inject padding bytes between B and T2 ... to keep T2 properly dword aligned (or more, ...
    (alt.lang.asm)
  • Re: RosAsm injects extra bytes into your data
    ... the ugly part is that he aligns bytename on a dword ... when clearly everyone knows that I have just a year of asm programming. ... problem occurs when you decide that for readability purposes, you want to split apart your declaration sections and declare your variables close to the points in the program where they are used. ... You dont know what it is, and you dont know that it is trivial to have in RosAsm. ...
    (alt.lang.asm)
  • Re: RosAsm Team is Still Making Excuses
    ... And what that means is that if you *must* pick only a single alignment ... dword is a good choice. ... What is RosAsm "working around?" ... A declaration section is a sequence of declarations in which all ...
    (alt.lang.asm)