Shop Learn
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 14 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

11112141617160

Comments

  • Dave HeinDave Hein Posts: 6,331
    edited 2015-10-12 22:44
    David Betz wrote: »
    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.
    Seairth wrote: »
    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.

  • RaymanRayman Posts: 12,185
    edited 2015-10-12 23:54
    I was OK with it the way it was...
    Apostrophe wouldn't be my first choice as it overlaps with comments

    Also, this doesn't look good:
    jmp	blink		'do it again
    

    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?
  • cgraceycgracey Posts: 13,619
    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.

    Any ideas?
  • cgraceycgracey Posts: 13,619
    edited 2015-10-12 23:57
    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.
  • RaymanRayman Posts: 12,185
    Any chance labels starting with ":" would indicate a relative branch when used in a jump?
  • 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.
  • RaymanRayman Posts: 12,185
    edited 2015-10-13 00:05
    I guess relative jumping could also be a separate command like "JMPR" or something...

    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...
  • cgraceycgracey Posts: 13,619
    Rayman wrote: »
    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.
  • What about &label or something to explicitly denote relative jumps?
  • cgraceycgracey Posts: 13,619
    What about &label or something to explicitly denote relative jumps?

    That's not bad.

    #label
    &label
  • Chip,

    [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?
  • RaymanRayman Posts: 12,185
    Yes, I think "address of" when I see "&" in code. I guess that could work here although it's not exactly the same.
  • 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.
  • RaymanRayman Posts: 12,185
    edited 2015-10-13 00:23
    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...
  • jmgjmg Posts: 14,813
    cgracey wrote: »
    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,

    JMP [register]
    is used by x86:intel mode.

  • jmgjmg Posts: 14,813
    cgracey wrote: »
    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$:’. "]

  • jmgjmg Posts: 14,813
    cgracey wrote: »
    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... ?

  • cgraceycgracey Posts: 13,619
    edited 2015-10-13 01:15
    I just made it so local labels begin with "_", instead of the old ":".

    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".
    load		mov	ptra,basev	
    
    		decod	count,#9
    _long		mov	bits,#32
    
    _bit		call	rx_bit
    		rcl	data,#1
    		djnz	bits,_bit
    
    		wrlong	data,ptra++
    		djnz	count,_long
    
    		coginit	#0,basev
    
  • cgraceycgracey Posts: 13,619
    jmg wrote: »
    cgracey wrote: »
    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.

    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.
  • jmgjmg Posts: 14,813
    edited 2015-10-13 01:42
    cgracey wrote: »
    I just made it so local labels begin with "_", instead of the old ":".

    This makes locals look better and frees up ":" for something else.

    Most assemblers (including as) use this
    ["A label is written as a symbol immediately followed by a colon : "]
    so the code becomes as below
    cgracey wrote: »
    Underscores "_" are allowed in labels, along "0".."9", but labels must begin with "A".."Z".
    load:		mov	ptra,basev	
    
    		decod	count,#9
    _long:		mov	bits,#32
    
    _bit:		call	rx_bit
    		rcl	data,#1
    		djnz	bits,_bit
    
    		wrlong	data,ptra++
    		djnz	count,_long
    
    		coginit	#0,basev
    

    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)

  • Dave HeinDave Hein Posts: 6,331
    edited 2015-10-13 01:40
    cgracey wrote: »
    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.

    !!
    $$
    ::
    ;;
    ??


  • cgraceycgracey Posts: 13,619
    edited 2015-10-13 01:42
    Dave Hein wrote: »
    cgracey wrote: »
    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?
  • cgracey wrote: »
    Dave Hein wrote: »
    cgracey wrote: »
    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.

  • jmgjmg Posts: 14,813
    cgracey wrote: »
    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.
    yes.
    cgracey wrote: »
    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 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.

  • Dave HeinDave Hein Posts: 6,331
    edited 2015-10-13 02:05
    cgracey wrote: »
    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.

  • jmgjmg Posts: 14,813
    edited 2015-10-13 02:07
    cgracey wrote: »
    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

  • cgracey wrote: »
    You must have some practice in mind, like starting constant labels with "_", or something like that?

    The current spin language has predefined constants that start with an underscore. They're all stated to be "one time settable".
  • potatoheadpotatohead Posts: 10,199
    edited 2015-10-13 02:50
    Hope we resolve this soon!

    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...

  • jmgjmg Posts: 14,813
    David Betz wrote: »
    The C compiler prefixes symbols with "_" so GAS probably won't be able to follow this convention.
    Very good point, best avoid _ - is the period prefix for local ok. Other asm's use that.
  • TorTor Posts: 2,010
    potatohead wrote: »
    "[ ]" No shift key on those too. Bonus!
    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..

    -Tor

Sign In or Register to comment.