Shop Learn
Propeller II update - BLOG - Page 17 — Parallax Forums

Propeller II update - BLOG

11415171920223

Comments

  • David BetzDavid Betz Posts: 14,460
    edited 2011-05-27 11:08
    Roy Eltham wrote: »
    Bill,
    I'm confused. You seem to be asking for it to work exactly how it works (except the range is -16 to 15 not -32 to 31).

    RDLONG D, PTRA[+4] <-- does not change PTRA, just uses PTRA + 4 (longs) as the address
    RDLONG D, PTRA[++4] <-- does modify PTRA, pre incrementing by 4 longs, then reading from that address

    Is it that you want it to not do the scaling when it's not modifying the pointer? Or what?

    Hi Roy,

    Is there any chance of uploading a PDF file with all of the instruction descriptions in the same place? It's great to read about them a few at a time but it would be nice to have a consolidated reference.

    Thanks,
    David
  • Roy ElthamRoy Eltham Posts: 2,995
    edited 2011-05-27 12:14
    Bill,
    Here are the bit fields for the RDxxxx and WRxxxx stuff:
    000000 EE01CCCC DDDDDDDDD 1SUPIIIII     WRBYTE  D,S/#n/PTR
    000000 E011CCCC DDDDDDDDD 1SUPIIIII     RDBYTE  D,S/#n/PTR
    000001 EE01CCCC DDDDDDDDD 1SUPIIIII     WRWORD  D,S/#n/PTR
    000001 E011CCCC DDDDDDDDD 1SUPIIIII     RDWORD  D,S/#n/PTR
    000010 EE01CCCC DDDDDDDDD 1SUPIIIII     WRLONG  D,S/#n/PTR
    000010 E011CCCC DDDDDDDDD 1SUPIIIII     RDLONG  D,S/#n/PTR
    
    For these instructions the top bit of the source field is always 1, so you only have 8 bits to work with, and that's why the range is one bit less than you expected. E is for effects (z,c,r) as in the WZ, WC, WR, etc stuff. I am not certain what N is, perhaps Chip will chime in.

    David,
    I don't have a complete file of all this yet. I am composing the information from notes I took while talking with Chip about it. Once I have all the stuff composed, I'll make a single file with all of it.

    Also, I will be starting a different thread for these instruction descriptions.
  • Bill HenningBill Henning Posts: 6,445
    edited 2011-05-27 12:41
    Thanks Roy.

    I suspect 'S' selects PTRA or PTRB

    Don't know U & P..... Hmm..

    Maybe U = Update the pointer
    and if P selects between pre- or post- update, it all makes sense - including the offset range!

    It's making sense now, if the above is correct.
    Roy Eltham wrote: »
    Bill,
    Here are the bit fields for the RDxxxx and WRxxxx stuff:
    000000 EE01CCCC DDDDDDDDD 1SUPIIIII     WRBYTE  D,S/#n/PTR
    000000 E011CCCC DDDDDDDDD 1SUPIIIII     RDBYTE  D,S/#n/PTR
    000001 EE01CCCC DDDDDDDDD 1SUPIIIII     WRWORD  D,S/#n/PTR
    000001 E011CCCC DDDDDDDDD 1SUPIIIII     RDWORD  D,S/#n/PTR
    000010 EE01CCCC DDDDDDDDD 1SUPIIIII     WRLONG  D,S/#n/PTR
    000010 E011CCCC DDDDDDDDD 1SUPIIIII     RDLONG  D,S/#n/PTR
    
    For these instructions the top bit of the source field is always 1, so you only have 8 bits to work with, and that's why the range is one bit less than you expected. E is for effects (z,c,r) as in the WZ, WC, WR, etc stuff. I am not certain what N is, perhaps Chip will chime in.
  • jmgjmg Posts: 14,940
    edited 2011-05-27 15:31
    Did the Prop II gain zero overhead loops (as seen in DSPs) ?
    The seriously limited primary code memory, makes the usual loop-unrolling rather less an option than on most other controllers.
  • jmgjmg Posts: 14,940
    edited 2011-05-27 15:36
    jazzed wrote: »
    What happens if we want to read or write all pins at once?
    I suppose there is no such mov or other on cog instruction.
    Can something like "rdquad pins, hubptr" read all pins at once?

    That's not really an opcode level problem ?
    If it was important enough to include, it could be done the same way 8 bit uC manage 16b writes, with a simple flag queue - writes go into buffers until the last one, which transfers everything.

    Where would someone need to update all pins at once ? { buying a ground bounce worst case }

    I can see that pin swap freedom on ports would allow tighter PCB designs, but users might not want ALL port writes queued, and now that gets more complex...
  • Cluso99Cluso99 Posts: 18,054
    edited 2011-05-27 20:23
    Chip,

    I still question the use of pinx as a reserved word, because of the confusion it can cause. It would be better to force programmers to write inx and outx and to flag errors when they are used inappropriately. Programs would not only be more reliable, but also more readable, since the syntax would correlate with the intent. If this were done, I think something like test ina,#1 would be a little less objectionable, since the intent is much clearer from the syntax than test pina,#1. In any event, I see no reason to go back to having inx and outx occupy separate addresses.

    -Phil

    I am in total agreement with Phil's comments here. No need to have separate INx and OUTx locations, just make the compiler do it properly to avoid coding errors.

    Now what makes more sense is to use the compiler to reposition the source and destination registers according to what is really being done, not how the propII actually formats the instructions.

    WRxxxx hubptr, [#]data
    RDxxxx cogdata, [#]hubptr <
    reversed to the current compiler, but makes more sense to a programmer

    mov data, INx
    mov OUTx,[#]data

    we could also have (if the instruction set permits, which seems to be the case). The compiler just handles it.

    test INx,[#]data
    test OUTx,[#]data

    The only issue I see in having the compiler placing the source/destination in the appropriate bits is that the MOVS and MOVD instructions become a little more obscure, but I think this is outweighed by the normal programming structure.

    I definately do not want our nice, powerful, and fancy new instructions make the PropII instruction set be so complex that it looks like a dogs breakfast (as is the case in some other micros). In fact, I think it would be nice for the Prop II to have two lists of instructions, one being the "regular" normally used instructions and the others being the "super" instructions for complex operations. In other words, hide the complexities from those who don't care.

    What do others think???
  • Cluso99Cluso99 Posts: 18,054
    edited 2011-05-27 20:40
    Roy Eltham wrote: »
    New pointer registers and instructions on Prop 2:

    On all hub memory read instructions, S can be replaced with a PTRA or PTRB. Also for hub writes, D can be replaced with PTRA or PTRB. There are several ways to use the PTRx registers with hub access instructions.
    Note: The range for the constants inside the []'s below is -16 to +15 (5 bits signed) However, this value is scaled by the size of the RD or WR you are doing. 1 for RD/WRBYTE, 2 for RD/WRWORD, 4 for RD/WRLONG, and 16 for RD/WRQUAD.
     
    RDLONG D, PTRA - reads the hub address that PTRA points to
    RDBYTE D, PTRB[+3] - reads the hub address that PTRB+3 points to
    RDLONG D, PTRA[++2] - pre-increment PTRA by 2 longs (so actually adding 8 to PTRA), then read the hub address that PTRA now points to
    RDLONG D, PTRB[6--] - reads the hub address that PTRB points to, then post decrement PTRB by 6 longs (so actually subtracts 24 from PTRB)
    WRLONG D, PTRB - writes to the hub address that PTRB points to
    WRWORD D, PRTA[++4] - pre increments PTRA by 4 words (advancing PTRA by 8), then writes to the hub address that PTRA now points to
    
    These work with all forms of RDxxxx & WRxxxx, including the new RDQUAD/WRQUAD, and the cached read versions of RDxxxxC. Something else to note is that when doing RD/WR instructions with a constant, like RDLONG D, #xxx, the range of xxx is now limited 0 to 255 instead of 0 to 511. That upper bit is used to indicate using PTRx stuff.

    Also, the compiler/assembler will be able to shorthand PTRx[++1] to ++PTRx along with all the other variants of pre/post inc/dec by 1.

    I will post more later about RDQUAD/WRQUAD, and the cached RDxxxxC instructions.

    I (too) overlooked the fact that you can access an offset to the pointer.
    RDBYTE D, PTRB[+3] - reads the hub address that PTRB+3 points to
    

    So you can access
    * an offset to the pointer
    * pre-increment the pointer
    * post-decrement the pointer

    So, the instruction set is aiding stack and high level instructions. However, a fast block load can still be achieved, but it must be remembered either that the first access should not pre-increment, or that the pointer must first be decremented.

    I would have preferred the options of none/pre/post increment/decrement but realise there is a lack of bits. However, I am quite happy with what has been discussed.
  • Roy ElthamRoy Eltham Posts: 2,995
    edited 2011-05-27 20:42
    I don't like the idea of hiding what is actually happening from the programmer. Either stick with the PINx notation, or split the registers like in Prop 1. To me it is most important that things be clear.

    Also, using the mapped registers as storage when not doing I/O is not really something that needs to be retained, especially given the tons of extra storage available now.
  • jazzedjazzed Posts: 11,803
    edited 2011-05-27 20:48
    jmg wrote: »
    That's not really an opcode level problem ?

    I'm thinking of a case like a 96 channel logic analyzer ... PPLA2 for example or a stand-alone LA product. A logic analyzer needs simultaneous sampling. With that Propeller 2 would make a very good multi-channel Logic Analyzer processor :)

    A logic tester might want many pins asserted at once (not a popular thing these days).

    If ground bounce is really a problem, then that's fine.
  • Cluso99Cluso99 Posts: 18,054
    edited 2011-05-27 20:49
    Perhaps the U stands for UP as in INCREMENT (or DECREMENT) ???

    Since we have pre-increment and post-decrement and none, could we also have post increment???
  • Roy ElthamRoy Eltham Posts: 2,995
    edited 2011-05-27 21:33
    Cluso99,
    The PTRx stuff already supports all the combinations. Pre/Post/None & Inc/Dec. There is a bit to select the pointer (A or B), a bit to indicate if it's should modify the pointer or not, and a bit to select between pre and post when modifying. The range is signed -16 to +15.
    You can do PTRx[++n], PTRx[n++], PTRx, or PTRx[n--] and it will modify the pointer. Also, you can do PTRx[+n] or PTRx[-n] and it will not modify the pointer.
    The examples in my original post were not exhaustive.

    I guess need to be a bit more careful posting these descriptions. To be sure that you all properly understand how they work.
  • SSteveSSteve Posts: 808
    edited 2011-05-27 22:03
    Cluso99 wrote: »
    I am in total agreement with Phil's comments here. No need to have separate INx and OUTx locations, just make the compiler do it properly to avoid coding errors.
    Roy Eltham wrote: »
    I don't like the idea of hiding what is actually happening from the programmer. Either stick with the PINx notation, or split the registers like in Prop 1. To me it is most important that things be clear.

    Since they'd both wind up as the same opcode, why not have both? Let the programmer use PINx if he understands how it works and use INx/OUTx if he wants some hand-holding from the compiler.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,295
    edited 2011-05-27 22:07
    Roy Eltham wrote:
    I don't like the idea of hiding what is actually happening from the programmer. Either stick with the PINx notation, or split the registers like in Prop 1. To me it is most important that things be clear.
    So I suppose you'd also like to get rid of the test instruction, too, and force people to use and with nr in order not to hide the architectural details? Come on, Roy. There are a ton of details that are hidden in the Prop now that make programs more readable and reliable. By deprecating inx and outx and requiring the use of pinx, users are forced to remember rules which, if they're the tiniest bit obscure, will lead to programming errors and tech support headaches for Parallax. The idea is to make PASM programming productive, not ivory-tower pure, and to make programs say what they mean. Remember: pinx is not a register; but inx and outx are registers -- different registers that just happen to occupy the same address.

    Conversely, the consequences of separating inx and outx to occupy different addresses are dire, since even more SFR addresses get gobbled up, forcing four more SFRS into the special-access shadows where it's less convenient to use them.

    -Phil
  • Roy ElthamRoy Eltham Posts: 2,995
    edited 2011-05-27 22:23
    Phil,
    I think it goes a bit farther than test actually being and with nr. In the end, I will trust Chip to do what he feels is best. I think if it was up to me and I had to decide right now, I would split them like the Prop1. Only because it keeps things the same as before and is a bit more clear. I believe that right now the Prop2 only has 8 mapped registers, so it would go to 12 mapped registers, and that still 4 less than the Prop1.

    However, in my Prop coding so far, I have yet to use the I/O pins in a way that would not work with it just being PINx like Chip has it on the Prop2. I've never had a situation where I needed to read back from OUTA, or write to INA. I tend to read INA into another variable, and then do tests on that variable. and likewise I tend to build my output into a variable and then write that to OUTA. So it would work just fine with the PINx stuff.

    Roy
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,295
    edited 2011-05-27 22:40
    Roy Eltham wrote:
    I believe that right now the Prop2 only has 8 mapped registers...
    It must have more than that. The essentials for being mapped are dira - dird, pina - pind, frqa, frqb, probably par, and (I would hope) cnt. That's twelve already. (If there aren't a full sixteen, I would have to question -- again -- why phsa and phsb couldn't be mapped here.)

    I agree with you that ina and outa are used so differently that it's unnecessary for them occupy different addresses. I just think it's a cruel trick to make programmers (and those who read their programs) remember the context rules for some illusory "pinx", when the assembler could easily handle references to, and flag misuse of, inx and outx.

    -Phil
  • Roy ElthamRoy Eltham Posts: 2,995
    edited 2011-05-28 01:29
    Phil,
    The registers cnt, frqa and frqb are not mapped, and par doesn't exist anymore, it's functionality is replaced by ptra and ptrb (which are not mapped).
  • SapiehaSapieha Posts: 2,964
    edited 2011-05-28 01:51
    Hi All.

    Question to them that will have mapped registers.

    Why have that IF instructions to handle hidden registers to them have same possibilitys that any Mapped ones AND free space for usable programs?
  • Cluso99Cluso99 Posts: 18,054
    edited 2011-05-28 02:35
    Sapieha: I am not sure what you are asking.
  • SapiehaSapieha Posts: 2,964
    edited 2011-05-28 04:49
    Hi Cluso.

    In short term - Why so much talk on Mapped registers -- My standpoint -- As litle that ones as it is ever possible


    Cluso99 wrote: »
    Sapieha: I am not sure what you are asking.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-28 07:30
    I am glad that we are getting a clearer picture of what the instruction set and functionality of the Propeller II will be. I have large amounts of Propeller II code that I am rewriting due to the updated information. I am glad that many things are a lot simpler with the Prop II.

    Thank you Roy.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,295
    edited 2011-05-28 09:50
    So cnt is not mapped? How are we supposed to do this?
        neg   duration,cnt
        ...
        add   duration,cnt
    

    And why on earth exclude frqx from the memory mapping when it's so handy to do math operations on them? I don't get it. I hope Chip can explain his rationale.

    -Phil
  • Roy ElthamRoy Eltham Posts: 2,995
    edited 2011-05-28 11:10
    Phil,
    Is it really that bad to do a GETxxxx instruction to retrieve the register value, then do the math you want and finally do a SETxxxx instruction to update the register if needed?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,295
    edited 2011-05-28 11:19
    Yes, it really is that bad when you're trying to eke out as many nanoseconds of accuracy or real-time response as possible -- especially if, like you say, there are unoccupied slots in the former 16-long SFR address space going to waste. Besides, with only 496 instruction words available, needing three instructions to do what used to take one is a rather large hit. It seems that the elegant microcontroller whose counters I've loved to use (and abuse) is turning into a rather-more-difficult-to-hack microprocessor, to the delight of the big-iron folks, but not to me.

    -Phil
  • Mike GreenMike Green Posts: 23,101
    edited 2011-05-28 11:25
    Roy,
    It slows things down in situations likely to need very high speed. Sure the Prop II will be faster, but requiring multiple instructions to do what was doable in a single instruction before will lose some of the effective speed of the Prop II.
  • Roy ElthamRoy Eltham Posts: 2,995
    edited 2011-05-28 11:31
    With the instructions being effectively 1 clock, and the increased clock rate, you'll have significantly better accuracy or real-time response than you have on the Prop 1, even with the extra instructions needed to access the unmapped registers.

    I, honestly, don't have a strong opinion either way on this. I'd be fine with more mapped registers, or even less.
  • SapiehaSapieha Posts: 2,964
    edited 2011-05-28 11:38
    Hi Roy.

    I still wait for descriptive instruction set - But if I understand Counters will have now some extra functions TYPE auto reload and some other possibilitys that help much even if some times it need be reloaded.


    Roy Eltham wrote: »
    With the instructions being effectively 1 clock, and the increased clock rate, you'll have significantly better accuracy or real-time response than you have on the Prop 1, even with the extra instructions needed to access the unmapped registers.

    I, honestly, don't have a strong opinion either way on this. I'd be fine with more mapped registers, or even less.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,295
    edited 2011-05-28 11:44
    Roy Eltham wrote:
    With the instructions being effectively 1 clock, and the increased clock rate, you'll have significantly better accuracy or real-time response than you have on the Prop 1, even with the extra instructions needed to access the unmapped registers.
    True. But if it could be faster yet -- by a factor of three -- and not put additional burden on the limited space for instructions, returning the SFRs to the cog's memory space is a no-brainer. I can see no justification for hiding these registers if the memory space is available to expose them.

    -Phil
  • Bill HenningBill Henning Posts: 6,445
    edited 2011-05-28 13:09
    Roy,

    Phil and Mike have a good point. 3 instructions Vs. 1, often in more than one place, uses far more cog memory then putting those register back.

    My single cog hirez text driver have a patch from kuroneko that uses that style of manipulation.
    Roy Eltham wrote: »
    With the instructions being effectively 1 clock, and the increased clock rate, you'll have significantly better accuracy or real-time response than you have on the Prop 1, even with the extra instructions needed to access the unmapped registers.

    I, honestly, don't have a strong opinion either way on this. I'd be fine with more mapped registers, or even less.
  • jmgjmg Posts: 14,940
    edited 2011-05-28 16:05
    Yes, it really is that bad when you're trying to eke out as many nanoseconds of accuracy or real-time response as possible -- especially if, like you say, there are unoccupied slots in the former 16-long SFR address space going to waste. Besides, with only 496 instruction words available, needing three instructions to do what used to take one is a rather large hit. It seems that the elegant microcontroller whose counters I've loved to use (and abuse) is turning into a rather-more-difficult-to-hack microprocessor, to the delight of the big-iron folks, but not to me.

    -Phil

    Rather than trade-off here, why not do what many uC aleady do, and allow a run-time selection of exactly what is mapped ?
    Speed and Size are very important given the code memory map size.
    { which is also why I'm amazed there seems to be no zero overhead loop support }
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-28 16:27
    If we are going to have quad word read/write access to hub mem, this means that at effectively 40MIPS we will have 192K of code memory. So why are we so worried about this? If we have the registers back we still have a huge code space for most things, as very few things need that much speed, and it is proven that we can do it.
Sign In or Register to comment.