Chip has expressed a desire to intermix packed data with instructions and that makes non-aligned instructions necessary.
I guess one has to careful about what they wish for. Packed data and non-aligned access may seem like a good idea, but it's probably more trouble than it's worth.
I already don't like the tick mark. It is both visually subtle and and easy to confuse with the comment mark.
As for the removal of "@", I'm somewhat intrigued. Personally, I was fine with the "@", so I don't know what the value of removing it is.
I'm not a fan of the "`" character either. The alternative would be to continue to use the "@" character as a context-sensitive operator that has different meanings depending on how it's used. In addition to the relative-address operator it's also used as the hub address. In some variants of P1 Spin/Pasm it has the same effect as the "@@@" operator. In P1 Spin/asm the "@" operator produces the object offset when used in the DAT section and the hub address when used within a Spin method. And then there's the "@@" operator that object address to an object offset to produce an absolute hub address. I wonder how P2 Spin will work.
Well, we need something to denote relative, as opposed to absolute branching. I like "@" for this, but we can't also use "@" for address-of. Those two things got tangled up and even caused me confusion.
I forgot to state that now, since branch addresses can be expressed without "#" or "@", we needed some new way to express a register. I chose "[register_here]":
JMP routine 'could be @ or #
JMP @routine
JMP #routine
JMP [register]
This use of brackets only applies to branches, not logic instructions.
Cluso,
We'll have to see when we have actual silicon to test with.
I still disagree with you about hubexec being hotter. Hot spots on chips are generally caused by too many transistors in a small area being constantly activated. Since hubexec spreads around the power more across the chip, I don't see it causing problems. It's not much different than the cogs going to their own memories. When the heat generation is spread around the chip more it dissipates better. When it's localized to small areas it doesn't dissipate as well and means a hotter chip.
I see no problems at all running all 16 cogs in hubexec mode.
Any chance labels starting with ":" would indicate a relative branch when used in a jump?
We could do that, but we'd need to find another way to call out local labels. I think "_" as the first character would have been a nice way to denote local labels. ":" looks kind of operator-like.
[register] usually means indirect through the register, so that works. Although, I would prefer it be consistent, and be used everywhere, not just on branches. In fact, I think we could lose the # to mean immediate, and instead have it be no symbol = immediate, and [] means through register, then the @ can stay as it was beforee you made it the ` (which is awful).
C/C++ uses & to mean address of when it prepends an identifier (e.g. &routine = address of routine), maybe an option?
Rayman,
I think having a requirement that it be as close to P1 asm as possible is a bad place to start from. It limits us and forces odd constructs.
I think it's better to do for the P2 what makes it the best for the P2. The P2 is a very different beast with key differences that just don't fit the P1 mold.
Someone can make a translator program to convert P1 ASM to P2 ASM if need be.
I don't think it's a requirement to be like P1, but do think it's a good goal...
I remember learning 8086 assembly a long time ago and then 80x86 and there were some additions, but mostly it was the same. This is totally different but still I think it's a good idea to have the programmers feel comfortable, if possible.
They are calling this "P2", indicating that it's a progression, not something totally different...
I forgot to state that now, since branch addresses can be expressed without "#" or "@", we needed some new way to express a register. I chose "[register_here]":
JMP routine 'could be @ or #
JMP @routine
JMP #routine
JMP [register]
This use of brackets only applies to branches, not logic instructions.
Direct label use is far more common in Assemblers, (least typing, more readable), and as you say that leaves branches...
Looking at gas docs, & others the
JMP @register
is used in 8051, MSP430, SH, Z8000, Mitsubishi’s D10V, D30V, H8, SuperH,
We could do that, but we'd need to find another way to call out local labels. I think "_" as the first character would have been a nice way to denote local labels. ":" looks kind of operator-like.
as has this for local labels .L or L, or you can
["2.7 Include Local Symbols: ‘-L’
Symbols beginning with system-specific local label prefixes, typically ‘.L’ for ELF systems or
‘L’ for traditional a.out systems, are called local symbols"]
and also
["Dollar Local Labels
as also supports an even more local form of local labels called dollar labels. These labels
go out of scope (i.e., they become undefined) as soon as a non-local label is defined. e.g., ‘55$:’. "]
Well, we need something to denote relative, as opposed to absolute branching.
I'm unclear on why this is needed ?
Can the assembler not choose the smallest, most portable form, when using a generic CALL or JMP, and if you want an explicit non-relative form for some reason, use a AJMP or LJMP or RJMP - that avoids yet another special character... ?
Well, we need something to denote relative, as opposed to absolute branching.
I'm unclear on why this is needed ?
Can the assembler not choose the smallest, most portable form, when using a generic CALL or JMP, and if you want an explicit non-relative form for some reason, use a AJMP or LJMP or RJMP - that avoids yet another special character... ?
Ah, make new mnemonics for the different types. Interesting.
That might work well. JMP would be the generic case that would follow some contextual rule, while AJMP/RJMP would force absolute/relative. I wonder if that would just clutter things up on the instruction side, though. It would get rid of both "#" and "@" for branches, which is nice.
It might be better to put the letter on the end. No, that's not going to work.
That gets kind of busy. Maybe we could use ":" to mean relative and "#" to mean absolute. That is a lot tidier. I think someone suggested using ":" for relative. If we did that, "@" could mean address-of.
I just made it so local labels begin with "_", instead of the old ":".
I guess there will always be somebody that disagrees with a change. In this case that person is me. Using "_" to prefix labels and variables is a very common practice, and that convention conflicts with using it for local labels. Could you please go back to using ":" for local variables?
You could use a double character for relative addresses. Here's a short list of possibilites.
I just made it so local labels begin with "_", instead of the old ":".
I guess there will always be somebody that disagrees with a change. In this case that person is me. Using "_" to prefix labels and variables is a very common practice, and that convention conflicts with using it for local labels. Could you please go back to using ":" for local variables?
None of us have written anything nearly useable yet, of course.
Here's how I see this: I understand what you are saying, but how much more often might we benefit from easier-to-look at local labels than being able to start normal labels with underscores?
You must have some practice in mind, like starting constant labels with "_", or something like that?
I just made it so local labels begin with "_", instead of the old ":".
I guess there will always be somebody that disagrees with a change. In this case that person is me. Using "_" to prefix labels and variables is a very common practice, and that convention conflicts with using it for local labels. Could you please go back to using ":" for local variables?
None of us have written anything nearly useable yet, of course.
Here's how I see this: I understand what you are saying, but how much more often might we benefit from easier-to-look at local labels than being able to start normal labels with underscores?
You must have some practice in mind, like starting constant labels with "_", or something like that?
The C compiler prefixes symbols with "_" so GAS probably won't be able to follow this convention.
Ah, make new mnemonics for the different types. Interesting.
That might work well. JMP would be the generic case that would follow some contextual rule, while AJMP/RJMP would force absolute/relative. I wonder if that would just clutter things up on the instruction side, though. It would get rid of both "#" and "@" for branches, which is nice.
It might be better to put the letter on the end. No, that's not going to work.
That looks ok
- What's not going to work, letter on the end ? - because there is already a suffix used for CALLA/CALLB/CALLD prefix looks cleaner.
The A/R prefix call forcing will be rare, surely ?
IIRC you said both absolute and relative can cross code boundaries ?
In most CPUs relative jumps are shorter/nearer, and absolute jumper are longer, and the generic CALL/JMP auto selects which to use, with the choice of SJMP/LJMP if desired.
None of us have written anything nearly useable yet, of course.
Here's how I see this: I understand what you are saying, but how much more often might we benefit from easier-to-look at local labels than being able to start normal labels with underscores?
You must have some practice in mind, like starting constant labels with "_", or something like that?
Yes, there is not a lot of P2 code yet, but there is a lot of P1 code that will be ported to the P2. Any deviations from P1 convention will make it that much harder to port code to P2. The p2pfth.spin code I posted has a few instances of prefixing labels with an underscore. These are mostly used to indicate primitive functions. I have other programs where I use _add and _sub to distinguish the labels from the keywords add and sub. Of course, I can change the code without too much trouble. I'm just letting you know that I prefer keeping the P1 designation for local labels.
Here's how I see this: I understand what you are saying, but how much more often might we benefit from easier-to-look at local labels than being able to start normal labels with underscores?
NASM uses a prefix period, and as allows a target defined choice. SO that is another ooption - it frees _ which is considered a legal char in many cases... .ThisIsLocalName: ...
JMP .ThisIsLocalName
Some ASMs I think allow an ASM directive to (re)define the local label prefix char, but maybe not as
I prefer shorter syntaxes, and ideally those that do not require people to repeatedly type in something globally defined all the time. Where we can boil it down to a character or two, great! Less to type, less to read.
Brackets for indirect seems good, and I agree with Roy in that it should be consistent for all indirection. "[ ]" No shift key on those too. Bonus!
I also prefer double characters. We've got one in use already for data specification, "%%" and those are really easy to see, unlike the tic.
The mixed instructions forms, letter here and there, seem to get really verbose. I'm not a fan. Where we can use a character or operator, it can work in other places too, very similar to how we see the same set of operators in SPIN and PASM being used in consistent ways. IMHO, this is worth a lot and should be a focus, where it can be.
On my keyboard "[ ]" needs alt Gr, which is worse than shift - so "( )" (need shift) is easier. But I don't think it's possible to avoid keyboard gymnastics. Just as long as we skip the backtick (`) idea..
Comments
Apostrophe wouldn't be my first choice as it overlaps with comments
Also, this doesn't look good:
I think in P1 you need a # in front or it will jump to the blink register value instead of the blink address. How does it know not to do that here?
Any ideas?
JMP routine 'could be @ or #
JMP @routine
JMP #routine
JMP [register]
This use of brackets only applies to branches, not logic instructions.
We'll have to see when we have actual silicon to test with.
I still disagree with you about hubexec being hotter. Hot spots on chips are generally caused by too many transistors in a small area being constantly activated. Since hubexec spreads around the power more across the chip, I don't see it causing problems. It's not much different than the cogs going to their own memories. When the heat generation is spread around the chip more it dissipates better. When it's localized to small areas it doesn't dissipate as well and means a hotter chip.
I see no problems at all running all 16 cogs in hubexec mode.
I would just prefer that syntax stays as close to P1 asm as possible...
I envision one day programming in both and it'd be easier the more alike they were...
We could do that, but we'd need to find another way to call out local labels. I think "_" as the first character would have been a nice way to denote local labels. ":" looks kind of operator-like.
That's not bad.
#label
&label
[register] usually means indirect through the register, so that works. Although, I would prefer it be consistent, and be used everywhere, not just on branches. In fact, I think we could lose the # to mean immediate, and instead have it be no symbol = immediate, and [] means through register, then the @ can stay as it was beforee you made it the ` (which is awful).
C/C++ uses & to mean address of when it prepends an identifier (e.g. &routine = address of routine), maybe an option?
I think having a requirement that it be as close to P1 asm as possible is a bad place to start from. It limits us and forces odd constructs.
I think it's better to do for the P2 what makes it the best for the P2. The P2 is a very different beast with key differences that just don't fit the P1 mold.
Someone can make a translator program to convert P1 ASM to P2 ASM if need be.
I remember learning 8086 assembly a long time ago and then 80x86 and there were some additions, but mostly it was the same. This is totally different but still I think it's a good idea to have the programmers feel comfortable, if possible.
They are calling this "P2", indicating that it's a progression, not something totally different...
Direct label use is far more common in Assemblers, (least typing, more readable), and as you say that leaves branches...
Looking at gas docs, & others the
JMP @register
is used in 8051, MSP430, SH, Z8000, Mitsubishi’s D10V, D30V, H8, SuperH,
JMP [register]
is used by x86:intel mode.
as has this for local labels .L or L, or you can
["2.7 Include Local Symbols: ‘-L’
Symbols beginning with system-specific local label prefixes, typically ‘.L’ for ELF systems or
‘L’ for traditional a.out systems, are called local symbols"]
and also
["Dollar Local Labels
as also supports an even more local form of local labels called dollar labels. These labels
go out of scope (i.e., they become undefined) as soon as a non-local label is defined. e.g., ‘55$:’. "]
I'm unclear on why this is needed ?
Can the assembler not choose the smallest, most portable form, when using a generic CALL or JMP, and if you want an explicit non-relative form for some reason, use a AJMP or LJMP or RJMP - that avoids yet another special character... ?
This makes locals look better and frees up ":" for something else.
Underscores "_" are allowed in labels, along "0".."9", but labels must begin with "A".."Z".
Ah, make new mnemonics for the different types. Interesting.
That might work well. JMP would be the generic case that would follow some contextual rule, while AJMP/RJMP would force absolute/relative. I wonder if that would just clutter things up on the instruction side, though. It would get rid of both "#" and "@" for branches, which is nice.
That would apply to:
JMP/AJMP/RJMP
CALL/ACALL/RCALL
CALLA/ACALLA/RCALLA
CALLB/ACALLB/RCALLB
CALLD/ACALLD/RCALLD
LOC/ALOC/RLOC
It might be better to put the letter on the end. No, that's not going to work.
That gets kind of busy. Maybe we could use ":" to mean relative and "#" to mean absolute. That is a lot tidier. I think someone suggested using ":" for relative. If we did that, "@" could mean address-of.
Most assemblers (including as) use this
["A label is written as a symbol immediately followed by a colon : "]
so the code becomes as below
That's a convention I often use, and as says "but each target may have its own set of local label prefixes.", so it can conform to that.
(as well as the Lstring: or nn$: locals, I guess & there is also explicit .local List,Of,Names form)
You could use a double character for relative addresses. Here's a short list of possibilites.
!!
$$
::
;;
??
None of us have written anything nearly useable yet, of course.
Here's how I see this: I understand what you are saying, but how much more often might we benefit from easier-to-look at local labels than being able to start normal labels with underscores?
You must have some practice in mind, like starting constant labels with "_", or something like that?
That looks ok
- What's not going to work, letter on the end ? - because there is already a suffix used for CALLA/CALLB/CALLD prefix looks cleaner.
The A/R prefix call forcing will be rare, surely ?
IIRC you said both absolute and relative can cross code boundaries ?
In most CPUs relative jumps are shorter/nearer, and absolute jumper are longer, and the generic CALL/JMP auto selects which to use, with the choice of SJMP/LJMP if desired.
NASM uses a prefix period, and as allows a target defined choice. SO that is another ooption - it frees _ which is considered a legal char in many cases...
.ThisIsLocalName:
...
JMP .ThisIsLocalName
Some ASMs I think allow an ASM directive to (re)define the local label prefix char, but maybe not as
The current spin language has predefined constants that start with an underscore. They're all stated to be "one time settable".
I prefer shorter syntaxes, and ideally those that do not require people to repeatedly type in something globally defined all the time. Where we can boil it down to a character or two, great! Less to type, less to read.
Brackets for indirect seems good, and I agree with Roy in that it should be consistent for all indirection. "[ ]" No shift key on those too. Bonus!
I also prefer double characters. We've got one in use already for data specification, "%%" and those are really easy to see, unlike the tic.
The mixed instructions forms, letter here and there, seem to get really verbose. I'm not a fan. Where we can use a character or operator, it can work in other places too, very similar to how we see the same set of operators in SPIN and PASM being used in consistent ways. IMHO, this is worth a lot and should be a focus, where it can be.
my .02...
-Tor