vasm/mot: data structures

[guy lateur]

I've been using RS to define some data structures, like this:

    EVEN
    rsReset                          ; start struct scrTxtMem
scrTxtMem_PtrTopBlank       rs.l 1   ; pointer to top blank
scrTxtMem_PtrTopOpen        rs.l 1   ; pointer to top open/visible area
scrTxtMem_PtrBottomBlank    rs.l 1   ; pointer to bottom blank
scrTxtMem_SizeOf            rs.w     ; end/size of struct scrTxtMem

This works as expected. Also see here: http://eab.abime.net/showthread.php?t=94746

I was doing this from memory recently, and assumed that I did not need to specify the number of parameters if I only wanted 1. So I assumed writing just

rs.l

was equivalent to writing

rs.l 1

. This is clearly not the case. I think it defaults to

rs.l 0

, but I'm not sure.

I've been looking in the manual for info on the syntax of the

rs.b|w|l

'directive' (?), but I can't seem to find much. I can info on the set/reset/clr directives for so/fo, and how rs is very similar, but nothing specific on defining the fields/properties of the rs/so/fo structure.

Am I missing something? And shouldn't it default to 1, instead of 0?

[arcanist]

I think this covers what the directive is actually doing:

<label> rs.<size> <expression>

Works like the so directive, with the only difference that the offset symbol is named __RS.

<label> so.<size> <expression>

Assigns the current value of the structure offset counter to <label>. Afterwards the counter is incremented by the instruction’s <size> multiplied by <expression>. Any valid M68k size extension is allowed for <size>: b, w, l, q, s, d, x, p. The offset counter can also be referenced directly under the name __SO.

The RS directive isn't specific to structures. It has other uses and so it's not too surprising the manual only defines the semantics of the label and how it's manipulated. The structure "fields" are just labels with convenient offsets from the base of the structure.

You're right that it doesn't clarify what happens when <expression> is omitted. It rather looks like the syntax should be rejected.

[guy lateur]

Originally Posted by arcanist

I think this covers what the directive is actually doing:
<snip>

Hehe, I did find that first manual entry, that refers to the second one, which, for some reason, I did not see. I guess it was getting late and I was getting tired. I did search for so.b and so on, but not for so.<size>.

Originally Posted by arcanist

You're right that it doesn't clarify what happens when <expression> is omitted. It rather looks like the syntax should be rejected.

I agree that it would probably make more sense to have it throw an error when you leave out the <expression>, something à la "you need to specify a number of instances for this field". Also, I'm not sure about why you'd ever want 0 instances of a field. Maybe to have it ready as a place holder, to be filled in later?

Anyway, thanks a lot for your help; I'm glad we've got this sorted out now. This had me bug hunting for a couple of hours yesterday..

[Bruce Abbott]

Originally Posted by guy lateur

I agree that it would probably make more sense to have it throw an error when you leave out the <expression>,

Apparently not, because...

vasm history
=============

- 1.7c (15.05.15)

o mot-syntax: Fixed RS.x without operand (same as RS.x 0).

Originally Posted by guy lateur

Also, I'm not sure about why you'd ever want 0 instances of a field. Maybe to have it ready as a place holder, to be filled in later?

Why have an 'RS.x' that creates zero 'instances' at all? Because often you need to know the size of a structure.

For a better understanding of what RS was designed to to, take a look at the structure macros it replaces. Here are some examples from exec/types.i:-

STRUCTURE MACRO          ; structure name, initial offset
\1        EQU   0
SOFFSET   SET   \2
          ENDM

ULONG     MACRO          ; unsigned long (32 bits)
\1        EQU   SOFFSET
SOFFSET   SET   SOFFSET+4
          ENDM

APTR      MACRO          ; untyped pointer (32 bits - all bits valid)
\1        EQU   SOFFSET
SOFFSET   SET   SOFFSET+4
          ENDM

STRUCT    MACRO          ; Define a sub-structure
\1        EQU   SOFFSET
SOFFSET   SET   SOFFSET+\2
          ENDM

LABEL     MACRO          ; Define a label without bumping the offset
\1        EQU   SOFFSET
          ENDM

The variable SOFFSET is manipulated by these macros in the same way that __RS is manipulated by the RS directives.

RS is more efficient than macros because the assembler has less to do, but I don't use it because:-

1. My standard header files are preassembled so there's no efficiency improvement.

2. Structure macros put more type information into the source, so you can see at a glance whether eg. your 4 byte entry is supposed to be an unsigned long or an address pointer.

3. Structure macros are closer in style to C structures, making it easier to port code from C to assembler.

[guy lateur]

Originally Posted by Bruce Abbott

Why have an 'RS.x' that creates zero 'instances' at all? Because often you need to know the size of a structure.

Hmm, I also tend to have 1

scrTxtMem_SizeOf rs.w

at the end of my structures, but I usually have a lot more

scrTxtMem_x rs.w 1

in there, which still makes 0 the wrong default to pick, in my opinion/cases.

Btw, another reason for having 0 instances could be to have multiple names for the same field. Maybe to help some kind of memory usage optimisation or something? Just thinking out loud, here..

Originally Posted by Bruce Abbott

For a better understanding of what RS was designed to to, take a look at the structure macros it replaces.

Thanks for the example and reasoning, I'll look into that.

[phx]

Originally Posted by guy lateur

I agree that it would probably make more sense to have it throw an error when you leave out the <expression>

Oh. Hmm...
It's always good when such a topic comes up here, because it makes me think about my decisions from the past again.

In fact, there should be an error! At least in Devpac-compatibility mode. Leaving the expression away was a shortcut, which I introduced in the PhxAss assembler many decades ago. And with vasm 1.7c I probably decided to make vasm behave the same, because some of my own sources depend on it.

But it never worked like this in any other assembler. Neither in Devpac, nor AsmOne, AsmPro, Barfly, SNMA, etc...

So I guess I will make it a vasm feature, which is disabled with -devpac compatibility option. Too bad I just tagged the V1.8e release for tomorrow.

Originally Posted by Bruce Abbott

Why have an 'RS.x' that creates zero 'instances' at all? Because often you need to know the size of a structure.

Exactly! It was needed for every structure I defined, so I decided at some point that I would like to leave the '0' away.

[guy lateur]

Originally Posted by phx

But it never worked like this in any other assembler. Neither in Devpac, nor AsmOne, AsmPro, Barfly, SNMA, etc...

So I guess I will make it a vasm feature, which is disabled with -devpac compatibility option.

Please let me understand this correctly: you are going to change the -devpac compatible behaviour to throw an error when the size is not specified? So I won't notice this change unless I specify -devpac compatibility? Is this correct?

Btw, my source still compiles with -devpac compatibility (phew!), but it throws quite a few warnings about data auto-alignment -- which are probably suppressable, though..

Originally Posted by phx

Too bad I just tagged the V1.8e release for tomorrow.

Don't worry about this not getting into 1.8e release. We're lucky enough to have you consider these kinds of questions, about decisions made tens of years ago (!), and update vasm where appropriate. Not a lot of dev environments come with this kind of support, I think..

[phx]

Originally Posted by guy lateur

Please let me understand this correctly: you are going to change the -devpac compatible behaviour to throw an error when the size is not specified?

Yes. Because real Devpac does the same.

So I won't notice this change unless I specify -devpac compatibility? Is this correct?

Correct.

Btw, my source still compiles with -devpac compatibility (phew!), but it throws quite a few warnings about data auto-alignment -- which are probably suppressable, though..

Be careful here! That could be bad data alignments in your source. Something like...

        even
        dc.b    1
label:
        dc.w    2

...would be assembled by vasm in default mode without warning and does exactly what is written in the source: it writes the word $0002 at an unaligned address. When you access the word at "label" on the 68000 or 68010 your program will cause an alignment exception (AKA address error, Guru #3).

Devpac has auto-alignment enabled. But unlike the real Devpac vasm warns about all those auto-alignments, so you can check and fix them.

[guy lateur]

Originally Posted by phx

Be careful here! That could be bad data alignments in your source.

Originally Posted by phx

Devpac has auto-alignment enabled. But unlike the real Devpac vasm warns about all those auto-alignments, so you can check and fix them.

Ok, thanks for the heads up. It seems I'm lucky to be targeting and testing on an A1200/020, then..

So I guess I should probably have devpac compatibility turned on at all times? It feels a bit weird, though, because it says in the manual that 'Only directives known to Devpac are recognized', which feels like a step back with respect to the more modern developments of vasm. Or will I just be getting the best of both worlds in that case?

[phx]

Originally Posted by guy lateur

Ok, thanks for the heads up. It seems I'm lucky to be targeting and testing on an A1200/020, then..

Or rather unlucky that the bugs haven been hidden so long. Except you don't care for 68000 compatibility.

So I guess I should probably have devpac compatibility turned on at all times?

No. It just exists for assembling old sources, or to test compatibility when you want to guarantee that it assembles the same on Devpac.
Most (all?) Devpac features can be enabled in standard vasm mode with options or directives. Automatic data alignments just need the -align option.

[guy lateur]

Originally Posted by phx

No. It just exists for assembling old sources, or to test compatibility when you want to guarantee that it assembles the same on Devpac.

Ok I see, then I probably will have not much use for it, as I don't have any old sources to compile, and I don't see any requirement to compile my source with Devpac. At least not for now..

Originally Posted by phx

Most (all?) Devpac features can be enabled in standard vasm mode with options or directives. Automatic data alignments just need the -align option.

Alright, got it, thanks!