Help requested with PASM data alignment

RossH

I have a question for the various SPIN/PASM compiler suppliers (mpark, bradc, Parallax, ...) about data alignment in PASM.

I have been using data declarations with no data elements in Catalina to ensure the correct alignment of the following data elements, without wasting any unnecessary RAM space. For example (this is from memory, so apologies if the syntax is incorrect) ...

   DAT

   BYTE 1

label1     ' because of the preceeding BYTE declarations, label1 will not be LONG aligned

   BYTE 2    ' this byte will follow immediately after the preceeding bytes, and label1 will point to it

   LONG   ' <---- data declaration without data elements - I expect this to force LONG alignment without wasting any unecessary space

label2     ' because of the preceeding LONG, I expect label2 to be LONG aligned

   BYTE 3 ' because of the preceeding LONG, this byte will be LONG aligned, and I expect label2 to point to it

This was based on my reading of page 208 of the Propeller manual. However, while this seems to work with the Parallax Spin compiler and also with Brad's Spin Tool, it does not seem to work with Homespun - label2 is not LONG aligned, and does not point to byte '3' - I have not actually checked, but I suspect it points to the filler byte inserted after byte '2'. Re-reading the manual, I am now not sure who is correct, since the manual says the alignment of the data elements that follow the LONG will be affected, but it does not mention the alignment of any label that follows it. The manual also does not seem to support the common practice of putting a label on a line by itself - perhaps this contributes to the problem since putting 'label2 BYTE 3' on the same line would probably work.

I have the following questions:

1. Should saying 'LONG' by iself force alignment on a long boundary (and similarly with WORD for a word boundary) of following labels as well as data elements?

2. Is it correct syntax to have a label on a line by itself?

3. Is there another way to force the correct data alignment of a label without wasting unnecessary space?

Thanks,

Ross.

P.S. Just wanted to to make it clear - I know about this thread http://forums.parallax.com/showthread.php?p=694398 which discusses similar issues - but my problem is not with the data alignment - it is with the label alignment.

Post Edited (RossH) : 5/6/2009 1:10:44 AM GMT

mpark

I believe you have found a bug in Homespun. I would expect the same behavior that you do.

RossH

Hi mpark,

I think so too - but it would be worth getting consensus from all the compiler builders on what is the correct behaviour here. Homespun is not actually doing anything in contravention of the manual (at least that I can find).

Ross.

mpark

I'm pretty sure we're all in agreement. Homespun's current behavior is a bug as far as I'm concerned.

ericball

PASM works on LONGs - there is no equivalent to RDBYTE when dealing with data in COG RAM. Therefore, a label on anything other than a LONG boundary doesn't make sense. Take the following non-sensical sample code:

      ORG  0
start MOV  start, #data
      BYTE 0
data  BYTE 1

What value is #data? 1.25? ·(Of course @data is completely reasonable and logical, but we're talking about PASM here.) #data = 1 would be my bet, as #data = 2 would imply the label causes padding, which would break @data.

This doesn't mean you can't use BYTE and WORD in data which is loaded into HUB RAM. Just make sure your labels are on LONG boundaries. (I'd recommend manually padding just so you don't get bitten by the assumption bug.) And don't forget it's little-endian - so the first BYTE is the LSByte of the resulting LONG.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114
NTSC color bars (template): http://forums.parallax.com/showthread.php?p=803904

Ariba

ericball

The Assembler can not know if a byte/word/long instruction is part of an Assembly code, or of a data section. And for data sections
you need not-long-aligned labels.

In your example: data has cog address 1 and is the second byte of the long starting at byte 0.
You even can access such a byte in PASM:

  mov t1,data
  shr t1,#((@data-@start)&3)*8
  and t1,#$FF

Andy

mpark

  [b]mov t1,data[/b] '<== doesn't compile because data is not long-aligned

I don't think it's correct to say that "data has cog address 1". As far as the compiler is concerned, data does not have a valid cog address.

RossH

Hi mpark,

I presume that all PASM labels can represent hub (byte) addresses, but that only labels that are also on long boundaries can represent a valid cog (long) address - and the relationship is something like cog address = (hub address - base address) / 4 ?

Ross.

P.S. I just sent you a PM on a related subject.

Post Edited (RossH) : 5/7/2009 6:17:40 AM GMT

mpark

As of version 0.25x, Homespun behaves as expected on the example in the first post.

Homespun thread: http://forums.parallax.com/showthread.php?p=749832