Shop OBEX P1 Docs P2 Docs Learn Events
The New 16-Cog, 512KB, 64 analog I/O Propeller Chip - Page 27 — Parallax Forums

The New 16-Cog, 512KB, 64 analog I/O Propeller Chip

12425272930144

Comments

  • koehlerkoehler Posts: 598
    edited 2014-04-13 14:49
    Sounds as though the hubexec issue is in the latter technical resolution stage.

    Somewhat concerned now about how much logic/power the "smart pins" are going to use.

    Maybe later in the design process explore a way to power-gate OFF a lot of this functionality/power in those pins?
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-13 15:00
    Won't that happen when the message to activate / deactivate the modes is used?
  • jmgjmg Posts: 15,140
    edited 2014-04-13 15:17
    potatohead wrote: »
    Won't that happen when the message to activate / deactivate the modes is used?

    Yes. The SysCLK is already routed to all the pins, for sampling work, so that clock-bus power is fixed,

    A Binary counter, Qn side, only draws as much power as two FF's toggling at fSys/.2

    The Clock tree to the counter register chain will draw some power, but it is very local and short.
    Likely that part will be Gated by the Activate command.

    Die-area is likely to be a larger issue, than power when looking at IO pin cells.
    (that and also meeting the 200MHz target)
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2014-04-13 15:49
    Phil,
    My first thought was: Isn't "cmps D, S wc, wr" the same as "subs D, S" ? However it looks like the C flag is handle a little differently for CMPS verses SUBS.

    I'm not sure if Chip did the change to drop the WR/NR bit from instructions or not, but I could see how they might be useful in some rare cases.
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-04-13 18:25
    There was some talk about repurposing the wr flag, since "it wasn't very useful." So I went through all my code to see how I had used wr and nr. Here's what I found:
                  cmps      dx,px wc,wr                   
                  cmps      dy,py wc,wr                   
                  cmps      dx,px wc,wr                   
                  cmps      dy,py wc,wr                   
    divabx        cmpsub    ra,rx wc,nr                                                       
                  cmps      manA,#0 wc, nr                             
    :zeroSubnormal or       manA,expA wz,nr                        
                  cmps      manA,#0 wc, nr                             
    :build_lp     or        :csdp,:csdn nr,wz                            
    :squ          shl       phase,#1 wc,nr                                               
            if_c  add       btn_shift,#1 wz,nr                                   
                  or        right_count,left_count nr,wz                            
                  shl       acc,#1 nr,wc
                  shl       outL,#1 wc,nr                                            
                  shl       phase1,#1 wc,nr                                 
                  shl       phase2,#1 wc,nr                               
            if_c  add       btn_shift,#1 wz,nr                                   
    :coord_ok     or        right_count,left_count nr,wz                            
    

    (Not shown are the instances where I could have used another instruction without the modifier.)

    Although I didn't use the modifiers very often, they were definitely useful when I needed them.

    -Phil
    The SHL (SHR,ROL,ROR) with NR can now all be replaced by ISOB so we have a solution here.
    I have used CMPSUB NR myself. Need to think about this one !!!
    CMPS WR is an interesting one. Need to think about this one !!!
    OR NR,WZ is a nice dual test for zero! Replace with 2x TEST instructions :(
    ADD x,#1 WZ,NR could be replaced with CMP x,allones WZ (allones long $FFFFFFFF - uses a register)
    CMPS x,y NR is just a CMPS x,y. No issue here.
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-04-13 18:27
    Roy Eltham wrote: »
    Phil,
    My first thought was: Isn't "cmps D, S wc, wr" the same as "subs D, S" ? However it looks like the C flag is handle a little differently for CMPS verses SUBS.

    I'm not sure if Chip did the change to drop the WR/NR bit from instructions or not, but I could see how they might be useful in some rare cases.
    They are gone.
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2014-04-13 18:44
    Hey guys,

    Sorry, I haven't been in this forum for a few days so this 40-freaking-page thread just popped up and I only had time to skim it, not read everything. If these are stupid questions that have already been answered, please forgive me.

    I really like the idea of going back to basics with the P1+ (or whatever this thing will be called), I thought the feature creep has been completely going out of hand since last year's failed shuttle run.

    Some things I haven't seen answered yet:

    1. So TV-out is gone, but if it will run at 200MHz and 100MIPS and it has D/A converters, shouldn't it be possible to generate CVBS from RGB data on the fly? Or at least convert RGB to YUV on the fly and use some external circuitry?

    2. If the instruction set is going to be source-compatible with the P1 but not binary-compatible, won't that break pretty much all self-modifying code? I bet there's a lot of that around, and it won't be possible to simply convert it automatically, it will have to be rewritten.

    Thanks!

    ===Jac
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-04-13 18:50
    I have been thinking about INDA/INDB and in particular to using them as pointers to a cog stack.

    The reason that a CALLINDA cannot be used is that in the second clock, the return address is written. It would also require INDA to be incremented and written.

    * Perhaps the CALLINDA could take 4 clocks, and the instruction itself perform the INC INDA in clocks 3 & 4.

    * Perhaps we could modify the fixed address $1EF CALL instruction to use INDA as a pointer to where the return address would be stored. For the fixed use case (GCC etc), the program would need to set INDA to $1EF (or wherever) at initialisation.

    With this change, we could use INDA as the pointer to a stack. INC and DEC of INDA would need to be performed by the subroutine like this...

    CALL SUB1 'uses [INDA] to store the return address.
    ...

    SUB1 ADD INDA,#1
    ...
    SUB INDA,#1
    RET 'uses [INDA] for the return address

    To PUSH and POP we would also have to use a group of instructions...
    ALTD INDA
    MOV 0,<value>
    ADD INDA,#1
    and
    SUB INDA,#1
    ALTS INDA
    MOV <get>,0

    While not ideal, it is a solution, and is faster than using hub. It only requires a minor change to the existing fixed CALL instruction, and gives the side effect of being able to set the fixed address anywhere in the cog when used as the fixed call.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-04-13 19:12
    Cluso99 wrote:
    The SHL (SHR,ROL,ROR) with NR can now all be replaced by ISOB so we have a solution here.

    SHR and ROR are alreday covered by the TEST d,#1 wc instruction.
    Cluso99 wrote:
    ADD x,#1 WZ,NR could be replaced with CMP x,allones WZ (allones long $FFFFFFFF - uses a register)
    The part in boldface ...
    Cluso99 wrote:
    CMPS x,y NR is just a CMPS x,y. No issue here.
    Oops! How'd that get in there? :)

    -Phil
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-13 19:24
    Given the nice DAC output, composite / component video will be possible in software at good signal quality.

    Not sure yet how color space conversions will get done. Maybe they just won't and we can use lookups and simple formulas to make it more simple.

    The hardware color space engine in the other design is too much of a beast for this process. IMHO, going VGA only makes sense. That really means software drivers like we did on P1, and we have a nice selection of those to port, and we get much better signal quality and color depth.

    We can look forward to the beast in the smaller process someday.

    I suppose a color lookup COG could get a lot of the functionality done. Or not, depending on what people need. With mor cogs in the mix, having one to do that might not be a worry. Color redirection was expensive on P1, unless it was two or 4 color. On this chip, it looks like we won't get any in hardware, but we get a lot more COGS!

    If desired, we still get the very high color depths though, and resolutions somewhere around XGA. Lower bit depths should still get us HDTV. Component isn't a huge challenge compared to VGA, but we will have to manage the DAC output for sync levels ourselves. Not sure what Chip has planned there.
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-04-13 19:30
    Video: I am really going to miss being able to do composite color. I like the cheap Car Reversing Monitors <$25 as they make nice screens.
    When the dust settles, maybe Chip might add it into one of the cogs on the quiet???
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-13 19:32
    Yeah, code will require rewrites, depending. This was going to be true no matter what. Code compatability was ruled out as a feature years ago. Waitvid changes, counters changes, pins get little brains right on them, the ROM changes and it's gonna be located at the beginning of RAM, taking up $e00 to $f00 or so. SPIN changes, we should see inline PASM, bigger programs, etc...

    But we get speed, lots of COGS, a huge HUB RAM space, smart pins, ability for a COG to run a PASM program out of the HUB memory directly, etc...

    That all means better, faster C performance and more library code makes sense, and it won't have to be LMM, so a lot of things just get a little nicer, easier, more roomy.

    @Cluso: Composite color will happen anyway. I use it all the time myself. If Chip can put it in, great! If not, we have good P1 code for doing it manually. Eric Ball was nice enough to entertain a couple of projects and got us there in a couple of useful ways.

    Should perform comparably to what the other design did, minus the nice color space hardware. I'm starting on it the moment we get an FPGA. TV is just too useful not to.
  • cgraceycgracey Posts: 14,133
    edited 2014-04-13 19:41
    Seairth wrote: »
    If you were to remove the increment/decrement functionality of INDx, then I'm guessing the use of INDx would be reduced to a MUX (with S/D) for the load. It would still require additional instructions to manipulate INDx, but that's not the critical function of those registers. Would that resolve the critical path timing issue?


    INDA/INDB had pre- and post- increment and decrement. We could achieve something similar by extending the ALTD/ALTS instructions:

    ALTDS	D/#,S/#	- set next D and S fields to D/# and S/#, respectively
    
    ALTD	D/#	- set next D field to D/#
    ALTS	D/#	- set next S field to D/#
    
    
    ALTD_PI	D	- Set next D field to D+1, increment D (pre-inc)
    ALTD_IP	D	- Set next D field to D,   increment D (inc-post)
    
    ALTD_PD	D	- Set next D field to D-1, decrement D (pre-inc)
    ALTD_DP	D	- Set next D field to D,   decrement D (inc-post)
    
    ALTS_PI	D	- Set next S field to D+1, increment D (pre-inc)
    ALTS_IP	D	- Set next S field to D,   increment D (inc-post)
    
    ALTS_PD	D	- Set next S field to D-1, decrement D (pre-inc)
    ALTS_DP	D	- Set next S field to D,   decrement D (inc-post)
    


    Wait! We could do even better by treating one D register as two separate 9-bit fields which get pre/post-inc/dec treatment based on some S/# pattern:

    ALTDS2 D,S/# - Set next D and S fields to some pre/post-inc/dec combination of D[17:9] and D[8:0]

    That way, one register can be two pointers, with separate controls. Ultimately, a two-instruction combo could, for example, be coded as:

    MOV [ptr1++],

    The D register fields could be modified, or not. This could make cog-RAM stacks easy to implement.
  • jmgjmg Posts: 15,140
    edited 2014-04-13 19:46
    cgracey wrote: »
    INDA/INDB had pre- and post- increment and decrement. We could achieve something similar by extending the ALTD/ALTS instructions:

    Sounds exactly what Bill was asking for in #768
    http://forums.parallax.com/showthread.php/155132-The-New-16-Cog-512KB-64-analog-I-O-Propeller-Chip?p=1259835&viewfull=1#post1259835
  • SeairthSeairth Posts: 2,474
    edited 2014-04-13 19:57
    Cluso99 wrote: »
    I have been thinking about INDA/INDB and in particular to using them as pointers to a cog stack.

    Maybe I'm missing something, but I would think that ALTD/ALTS would support the increment/decrement capability we know from INDx. If so, then PUSH would be:

    MOV [SP++], reg

    or

    ALTD SP++
    MOV 0, reg

    and POP would be:

    MOV reg,

    or

    ALTS --SP
    MOV reg, 0

    (note: I used "SP" instead of "INDA" to avoid confusion with the registers that were formerly at $1FE/$1FF, and no longer exist with this scheme.)

    Chip answered before I hit the submit button... he's covered it.
  • cgraceycgracey Posts: 14,133
    edited 2014-04-13 21:07
    I need to read a bunch of preceding posts to know what has been floated, but I think we only need ONE instruction to handle the whole indirect mechanism:

    ALTDS D,S/# - Selectively alter D and S fields in next instruction by using D as dual 9-bit pointers with S/# specifying the mode

    S/# = %ddd_sss

    ddd = 000: don't alter D field of next instruction
    ddd = 001: alter D field of next instruction by substituting current D[17:9]
    ddd = 010: <some mode we could define>
    ddd = 011: <some mode we could define>
    ddd = 100: alter D field of next instruction by substituting current D[17:9], increment current D[17:9]
    ddd = 101: alter D field of next instruction by substituting current D[17:9], decrement current D[17:9]
    ddd = 110: alter D field of next instruction by substituting current D[17:9]+1, increment current D[17:9]
    ddd = 111: alter D field of next instruction by substituting current D[17:9]-1, decrement current D[17:9]

    sss = 000: don't alter S field of next instruction
    sss = 001: alter S field of next instruction by substituting current D[8:0]
    sss = 010: <some mode we could define>
    sss = 011: <some mode we could define>
    sss = 100: alter S field of next instruction by substituting current D[8:0], increment current D[8:0]
    sss = 101: alter S field of next instruction by substituting current D[8:0], decrement current D[8:0]
    sss = 110: alter S field of next instruction by substituting current D[8:0]+1, increment current D[8:0]
    sss = 111: alter S field of next instruction by substituting current D[8:0]-1, decrement current D[8:0]


    Usage could be made simple by the assembler:
    MOVS    ptr,#from
    MOVD    ptr,#to
    REP     #count,#2
    MOV     [ptr++],[ptr++]           'move using pointers in ptr, this is actually two instructions: ALTDS and MOV
    
  • jmgjmg Posts: 15,140
    edited 2014-04-13 21:22
    cgracey wrote: »
    I need to read a bunch of preceding posts to know what has been floated, but I think we only need ONE instruction to handle the whole indirect mechanism:
    One core instruction, with control variants should certainly be ok and .cleaner assembler support is also a good idea.


    Did you mean to have two separate pointers here ?
    MOVS    ptrF,#from
    MOVD    ptrT,#to
    REP     #count,#2
    MOV     [ptrT++],[ptrF++]           'move using pointers in ptr, this is actually two instructions: ALTDS and MOV
    

    This also underlines the need for cleaner assembler version of REP (seems that is still in this ?), as the two count is not clear in the MOV, but is handled easily by the Assembler in this
    MOVS    ptrF,#from
    MOVD    ptrT,#to
    REP     #count,#_LoopS,_LoopE  ' Loop between _LoopS,_LoopE count times, Self adjusts and also checks for needed delays if any.
    :_LoopS
    MOV     [ptrT++],[ptrF++]      ' actually two instructions: ALTDS and MOV
    .. other code
    :_LoopE
    
  • cgraceycgracey Posts: 14,133
    edited 2014-04-13 21:25
    jmg wrote: »
    One core instruction, with control variants should certainly be ok and .cleaner assembler support is also a good idea.


    Did you mean to have two separate pointers here ?
    MOVS    ptrF,#from
    MOVD    ptrT,#to
    REP     #count,#2
    MOV     [ptrT++],[ptrF++]           'move using pointers in ptr, this is actually two instructions: ALTDS and MOV
    

    This also underlines the need for cleaner assembler version of REP (seems that is still in this ?), as the two count is not clear in the MOV, but is handled easily by the Assembler in this
    MOVS    ptrF,#from
    MOVD    ptrT,#to
    REP     #count,#_LoopS,_LoopE  ' Loop between _LoopS,_LoopE count times, Self adjusts and also checks for needed delays if any.
    :_LoopS
    MOV     [ptrT++],[ptrF++]      ' actually two instructions: ALTDS and MOV
    .. other code
    :_LoopE
    



    I don't know what to do about the pointer names. They are just different 9-bit fields within the same register.

    You're right about REPS needing some automation on the code size.
  • ozpropdevozpropdev Posts: 2,791
    edited 2014-04-13 21:25
    cgracey wrote: »
    I need to read a bunch of preceding posts to know what has been floated, but I think we only need ONE instruction to handle the whole indirect mechanism:

    ALTDS D,S/# - Selectively alter D and S fields in next instruction by using D as dual 9-bit pointers with S/# specifying the mode

    S/# = %ddd_sss

    ddd = 000: don't alter D field of next instruction
    ddd = 001: alter D field of next instruction by substituting current D[17:9]
    ddd = 010: <some mode we could define>
    ddd = 011: <some mode we could define>
    ddd = 100: alter D field of next instruction by substituting current D[17:9], increment current D[17:9]
    ddd = 101: alter D field of next instruction by substituting current D[17:9], decrement current D[17:9]
    ddd = 110: alter D field of next instruction by substituting current D[17:9]+1, increment current D[17:9]
    ddd = 111: alter D field of next instruction by substituting current D[17:9]-1, decrement current D[17:9]

    sss = 000: don't alter S field of next instruction
    sss = 001: alter S field of next instruction by substituting current D[8:0]
    sss = 010: <some mode we could define>
    sss = 011: <some mode we could define>
    sss = 100: alter S field of next instruction by substituting current D[8:0], increment current D[8:0]
    sss = 101: alter S field of next instruction by substituting current D[8:0], decrement current D[8:0]
    sss = 110: alter S field of next instruction by substituting current D[8:0]+1, increment current D[8:0]
    sss = 111: alter S field of next instruction by substituting current D[8:0]-1, decrement current D[8:0]


    Usage could be made simple by the assembler:
    MOVS    ptr,#from
    MOVD    ptr,#to
    REP     #count,#2
    MOV     [ptr++],[ptr++]           'move using pointers in ptr, this is actually two instructions: ALTDS and MOV
    

    Nice Chip!
    A cool variant of "TARG".
    Maybe one of the undefined modes could be used as a "NR" substitute. (Dummy write)
    Brian :)
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-04-13 21:41
    cgracey wrote: »
    I need to read a bunch of preceding posts to know what has been floated, but I think we only need ONE instruction to handle the whole indirect mechanism:

    ALTDS D,S/# - Selectively alter D and S fields in next instruction by using D as dual 9-bit pointers with S/# specifying the mode

    S/# = %ddd_sss

    ddd = 000: don't alter D field of next instruction
    ddd = 001: alter D field of next instruction by substituting current D[17:9]
    ddd = 010: <some mode we could define>
    ddd = 011: <some mode we could define>
    ddd = 100: alter D field of next instruction by substituting current D[17:9], increment current D[17:9]
    ddd = 101: alter D field of next instruction by substituting current D[17:9], decrement current D[17:9]
    ddd = 110: alter D field of next instruction by substituting current D[17:9]+1, increment current D[17:9]
    ddd = 111: alter D field of next instruction by substituting current D[17:9]-1, decrement current D[17:9]

    sss = 000: don't alter S field of next instruction
    sss = 001: alter S field of next instruction by substituting current D[8:0]
    sss = 010: <some mode we could define>
    sss = 011: <some mode we could define>
    sss = 100: alter S field of next instruction by substituting current D[8:0], increment current D[8:0]
    sss = 101: alter S field of next instruction by substituting current D[8:0], decrement current D[8:0]
    sss = 110: alter S field of next instruction by substituting current D[8:0]+1, increment current D[8:0]
    sss = 111: alter S field of next instruction by substituting current D[8:0]-1, decrement current D[8:0]


    Usage could be made simple by the assembler:
    MOVS    ptr,#from
    MOVD    ptr,#to
    REP     #count,#2
    MOV     [ptr++],[ptr++]           'move using pointers in ptr, this is actually two instructions: ALTDS and MOV
    
    That is smart Chip! As the instruction ALTDS can only write to D, combining the 2 pointers by using the D & S positions is great :)

    I have wondered if an AUGDS #d,#s might be useful ?
    One instruction can add the upper 9 bits (#D & #S) to both D & S of the next instruction (makes 18 bits total - we only need 17 for now, but nice to reserve 18 bits for sw compatibility if you make a 1MB hub version later.
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-13 21:41
    very nice indeed!
  • cgraceycgracey Posts: 14,133
    edited 2014-04-13 21:43
    ozpropdev wrote: »
    Nice Chip!
    A cool variant of "TARG".
    Maybe one of the undefined modes could be used as a "NR" substitute. (Dummy write)
    Brian :)


    Great idea!!!

    We've only got six bits specified for S/# in ALTDS, so we can use the three bits above to specify write-register alteration, with D[31:23] serving as the pointer for write redirection:

    ALTDS D,S/#

    S/# = %rrr_ddd_sss

    rrr = same as ddd/sss, but uses D[31:23] as a write redirection pointer.

    MOVI D,S/# can be used to set D[31:23]

    Now we've got it all in one instruction!!!
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-04-13 21:58
    cgracey wrote: »
    Great idea!!!

    We've only got six bits specified for S/# in ALTDS, so we can use the three bits above to specify write-register alteration, with D[31:23] serving as the pointer for write redirection:

    ALTDS D,S/#

    S/# = %rrr_ddd_sss

    rrr = same as ddd/sss, but uses D[31:23] as a write redirection pointer.

    MOVI D,S/# can be used to set D[31:23]

    Now we've got it all in one instruction!!!
    My first thought was you were going to change the next instruction's opcode.

    But what you have done is amazing. Hope it does not take much silicon.
    Could we perhaps use the CNT register for NR (It is a read only register)? Maybe a pseudo NR name?
  • jmgjmg Posts: 15,140
    edited 2014-04-13 22:08
    cgracey wrote: »
    I don't know what to do about the pointer names. They are just different 9-bit fields within the same register.

    Good point - Perhaps another approach to name overlaying above, would be a record-style syntax
    so the S and D sub-fields, are treated as records.
    MOV operand becomes generic, and Name.D -> MOVD, Name.S -> MOVS, Name.I -> MOVI
    As the opcode is identical, both syntax forms could be supported.

    MOV    ptr.S,#from
    MOV    ptr.D,#to
    REP     #count,#_LoopS,_LoopE  ' Loop between _LoopS,_LoopE count times, Self adjusts and also checks for needed delays if any.
    :_LoopS
    MOV     [ptr.D++],[ptr.S++]      ' actually two instructions: ALTDS and MOV
    .. other code
    :_LoopE
    
    In this ASM code, what is written is what actually happens, so it is easier to follow and edit than the naturally confusing form of

    MOV [ptr++],[ptr++] ' user wonders, is ptr +2 at the end of this ?

    whereas .D++ and .S++ shows clearly what is being INC'd - the 9 bit subfield records.
  • TubularTubular Posts: 4,620
    edited 2014-04-13 22:41
    This looks very nice

    Tiny point; I'd swap the increment and decrements over, so a '1' LSB corresponds to 'add one' (zero LSB would be the -- ) . Not a big deal, and yes the compiler would hide this anyway
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-13 22:58
    We really don't need extras on REP
    :_LoopS    REP     #count,#_LoopE-LoopS  
    
               MOV     [ptr.D++],[ptr.S++]  
               .. other code
    :_LoopE
    

    Rather than have the extra lines, can't we simply put something in the MOV instruction that indicates it's D & S fields are being modified?

    I find the whole record thing confusing personally, and I prefer MOVD and MOVS, because they will be used by themselves. Typically, we just label the instruction to be modified, and that's clear.
            movd        target, #value
    
            &#8230;some code
    
    target    mov        0-0, source
    
    

    Far easier to agree on a "ptr" convention, like we have done with "0-0" in the past to indicate the instruction itself is being modified.

    One thing I really like about PASM is that it doesn't need to be all that verbose, and it's expressive.
  • jmgjmg Posts: 15,140
    edited 2014-04-13 23:03
    potatohead wrote: »
    We really don't need extras on REP
            REP     #count, #:LoopE-:LoopS  
    :LoopS
            MOV     [ptr.D++], [ptr.S++]  
            .. other code
    :LoopE
    

    ? The typing of the two forms is exactly the same, but the benefit of the dual label form, is the first label can be syntax checked for any required preamble delays.
    Users cannot miss-format their REPS blocks using my simple approach.
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-13 23:14
    Sure they can.

    It's more verbose, and I would much rather keep that to a minimum, and:
        rep     #50, #3
        add    dest, #5
        and    dest, #1100
        mov    temp, dest
    
    
    

    Is still valid, brief, easy to read, while also permitting people to add the complexity where they want it, and where it will pay off. It won't always pay off, and when we get inline in SPIN, we may well want simple, easy to read PASM bits here and there. The less verbose the better, and that's what SPIN is about too, while both are easy to read.

    And are we even going to have delays? Chip?

    Splitting the middle:
    :loop1    rep     #50, #:loop2-:loop1
              add    dest, #5
              and    dest, #1100
    :loop2    mov    temp, dest
    

    Gets a nice, neat, vertically sparse block.
  • jmgjmg Posts: 15,140
    edited 2014-04-13 23:44
    potatohead wrote: »
    Sure they can.
    Nope, not without getting an error message.

    potatohead wrote: »
    It's more verbose, and I would much rather keep that to a minimum, and:

    If you apply that (quite strange) logic then you should be coding directly in HEX, after all,
    rep #50, #3

    Is more verbose than the most compact form of a hex opcode 0xabcd, and you have claimed you like to keep to a minimum.

    Why do you not do that now ?

    Simple, because you want the tools to do work for you. Let them work for others too.
    Most programmers I know (or would employ) consider code reliability way above file size.
  • jmgjmg Posts: 15,140
    edited 2014-04-13 23:48
    potatohead wrote: »
    Rather than have the extra lines, can't we simply put something in the MOV instruction that indicates it's D & S fields are being modified?

    Yup, sure,
    That's exactly what I have done above.
Sign In or Register to comment.