Packed/Aligned data
Seairth
Posts: 2,474
in Propeller 2
As discussed elsewhere, there is a need to control whether data is packed or aligned. Currently, all data and instructions in hub memory are packed. However, there are going to be times when a user specifically wants aligned data (and instructions) in the hub. In that case, there needs to be a way to force alignment. A variety of suggestions have been made. Here's my suggestion:
BYTE, WORD, and LONG align to their natural boundary. This is what people coming from P1 will expect.
PBYTE, PWORD, and PLONG indicated packed data. This make the intent clear (self-documenting).
Instructions are automatically long-aligned. Yes, this might waste up to 3 bytes. But it avoids requiring an additional directive or instruction to re-align instructions. No, I am not advocating that instructions should *only* be long-aligned (let's not start that argument again), just that the assembler won't do it. It doesn't stop the hub memory from being manipulated such that the instructions can be unaligned. It does not stop other languages from organizing hub memory however they want.
That's it. I'm sure some others out there will want to re-add their two cents...
BYTE, WORD, and LONG align to their natural boundary. This is what people coming from P1 will expect.
PBYTE, PWORD, and PLONG indicated packed data. This make the intent clear (self-documenting).
Instructions are automatically long-aligned. Yes, this might waste up to 3 bytes. But it avoids requiring an additional directive or instruction to re-align instructions. No, I am not advocating that instructions should *only* be long-aligned (let's not start that argument again), just that the assembler won't do it. It doesn't stop the hub memory from being manipulated such that the instructions can be unaligned. It does not stop other languages from organizing hub memory however they want.
That's it. I'm sure some others out there will want to re-add their two cents...
Comments
ie You cannot force one operational mode on users, (especially one that may use more memory) but this could be a global assembler control.
I'm not quite following the other point, but you do need to be able to create packed records in HUB memory, which can be any mix of 8,16,32 variables.
eg [8,16,8,32,32,8,8,16] should be declarable, and pack with no gaps.
yes, using this, which can be a MACRO until an Align keyword arrives.
I think Seairth is looking to avoiding using a lot of ALIGNS sprinkled in the code, so it does make sense to be able to tell the assembler
'from here on, Align 4 on opcodes', or 'from here on, align 1 on opcodes'.
Fair enough. Actually, I just noticed that ORGH already gets you some of the way there. In code, if you insert an ORGH $1000, then the image is zero-padded to $1000. The only thing that's missing here is a way to say "pad to the next alignment". In other words, suppose the following:
Depends on your use-case, and there may need to be added support if the intention is to be able to code in HUB, but also support copy of that relocatable block into COG at some later stage.
Section Align would help there, but I think you also need a check for accidental wrong VAR Placement within that 'portable' section too.
You keep saying this can be a MACRO or that can be a MACRO until some keyword is implemented, but as far as I know, PNUT does not support MACROs. Do you know how the MACRO feature works in PNUT? Can you write something up so we can all use these MACROs you are suggesting?
Your help would be appreciated by those of us out here trying to test the FPGA image and write code!!
Sorry for the small oversight. Please reword to say 'as a MACRO, when that is supported'.
Meanwhile, Google did find some interesting stuff...
Anyone know what happened to this/these ?
http://forums.parallax.com/discussion/93816/cross-platform-propeller-macro-assembler-and-loader
We will get a lean, clean syntax working with the limits of pnut. Good thing.
Once it's cooked and debugged, other tools can be made using pnut as a baseline minimum functionality test.
There are good macro assemblers out there too. Bending one to work in P2 land might be a great idea. Now that we have HUBEXEC, all assembly programs can make a lot of sense.
Pnut is most likely combo SPIN / PASM and may well be the source for the on chip tools, when that comes around.
My .02
I personally would just like to see ALIGN x with x being whatever is needed. 8, 16, 32, 64 whatever. X being bits. Maybe somebody wants to nibble align for packed data, for example. Just make it work for them.
And I say this because we allow for a lot of data representations now: binary, two bits, hex, decimal, strings, etc.... they could specify the alignment, then just dump the data right there, in whatever form works for them.
Between that and the organization statements we have, people could do what they need to, and do so easily.
Sounds good to me....
ALIGN 8 would not need to pack anything, but could reset an earlier ALIGN 32
How would ALIGN 4 work for nibbles ?
ALIGN LONG
causes confusion because LONG means so many different things these days, so that leaves BYTE or BIT aligns as numbers - either is fine really. ( as is ALIGN_32 etc )
There is some appeal to bits, as the trend for avoiding int/long confusion, is to specify int32, int64 instead. ( Implicit in that, is that int28 does not make sense.)
Octal data strings might align to hex digits, or nibbles, for example.
The cpu only sees bytes.
Labels are what the cpu sees.
But, if we are doing alignment, we might as well do all the cases in one shot.
Or, if that does not make sense, do byte, word, long and call it good. I don't care much.
So @Seairth Idea of having long, word, byte and plong, pword, pbyte for packed data is perfect.
It does not need any instruction, but can simply be done by the assembler/compiler/linker whatever.
Just insert zeroes and pad if needed.
It also is easy to understand. long, word, byte work like they do on the P1 and plong, pword, pbyte allow you to save space if it is needed.
aligning on bits seems to be not needed in my opinion.
Enjoy!
Mike
Let's not ask for too much here as it WILL take Chip away from P2 development to add anything special.
FWIW, for a compiler such as Roys' OpenSpin, how about..
* The default is long-aligned for code with an ALIGN OFF/LONG/WORD/BYTE command.
* The default is non-fill for ORGHUB $xxxxx (byte address) with an ORGHUB [LONG/WORD/BYTE,]$xxxxx[,FILL/NOFILL] (address is in long/word/byte, with byte as default, FILL fills with $00 from the current counter to the new address, NOFILL is the default and does not fill).
* The default for ORGCOG is cog address $000. ORGCOG [$xxx][,FILL/NOFILL] where $xxx = $000..$3FF (address is in longs and includes the LUT address space), and NOFILL is the default (does not fill between the current cog address and new address).
Please remember, pnut (PropTool) on the P1 re-organises hub memory (DAT blocks) for longs, words, and bytes. This has caught some people out, who assumed no reorganisation to compress code. Perhaps this needs a command options too?
Just give the programmer the choice if he want stuff aligned or not?
if you say long it will be aligned to a long address and padded to be so and if you say plong it will not be padded?
As a programmer you KNOW if you need alignment or not. Why the tools should guess about your intention?
Just write what you want into your source code.
seems to me the best solution.
Enjoy!
Mike