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

Propeller II update - BLOG

1217219221222223

Comments

  • SapiehaSapieha Posts: 2,964
    edited 2014-03-20 19:18
    Thanks
    ozpropdev wrote: »
    Its called TARG now
  • RossHRossH Posts: 4,696
    edited 2014-03-20 20:08
    Heater. wrote: »

    2) Making PASM code universally usable across all languages as binary blobs no matter if it was written in a Spin object or in GAS or whatever. Does Spin wrap address that ?

    Heater,

    I missed this bit earlier - I think you have nailed it. One of the main problems with the P1 is that PASM was never quite flexible enough to be used as a stand-alone assembler, and therefore was never quite flexible enough to be used as the basis for languages other than SPIN.

    It certainly can be done (as has been demonstrated by Catalina and others), but it requires some extensions to PASM (as implemented in Homespun and BSTC) - and even so it still needs quite a bit of messing about.

    If SPIN2 were to extend the PASM part of the language just slightly, then stand-alone PASM could be used not only in SPIN2, but also for portable objects, as well as for implementing higher-level languages that can use those same objects.

    And it wouldn't even take much - syntax-wise, PASM2 could be a simple superset of PASM so that P1 PASM code could still compile and run on the P2 (except where instruction semantics or the hardware changes, of course - but these cases can be easily documented, and the language could even warn you automatically of any such cases).

    While I think it would be a shame for existing P1 users if Parallax ditched the current PASM syntax and went with GAS, it would at least be workable (provided of course that GAS was also used as the assembler built into SPIN2).

    And at least we would all have a common foundation for all future P2 work.

    Ross.
  • potatoheadpotatohead Posts: 10,179
    edited 2014-03-20 21:10
    One of the main problems with the P1 is that PASM was never quite flexible enough to be used as a stand-alone assembler, and therefore was never quite flexible enough to be used as the basis for languages other than SPIN.

    That's because SPIN + PASM is one unified thing. And doing that is part of the magic which brought many of us here. To be honest, I find the idea of breaking it offensive. There is no way I want GAS mixed in with the core SPIN+PASM implementation.

    There is no reason to go breaking SPIN + PASM!

    Had something like plugging GAS into SPIN been the setup here when I arrived, I very likely would have moved on.

    Know what got me? I downloaded the data sheet and said, "Wow! This is crazy!" After looking around a little, I also thought, "bet it's hard to use too" Let's take a look...

    One quick download later and I was looking through the samples in the Prop Tool. What I saw was genius, simple, flexible, and something a person could grok right away. Bought a Demo Board that day. When it arrived, I was stunned at the number of things I really didn't need to know in order to make stuff happen. And all that power in one place. Simple! Just write it, hit F10 and go!

    Few things are that simple and powerful. Arduino makes the basics simple, but really doing magic takes considerable effort, and they've done a fine job with it all too. But, it's nothing like SPIN+PASM is. Frankly, nothing else is. Chip took a lot of the hassles out of this stuff, and that makes it fun as well as educational and productive.

    But there is more...

    C advocates here often ask what the deal is. Discussions like this really don't help the C cause. Not one bit. Ever wonder why people will just author killer things in SPIN+PASM? Did it ever occur to you guys that the reason why we get the contributions we do has something to do with how great, fun, productive, flexible, potent SPIN+PASM really is?

    I've gone and advocated we make sure C is excellent, and actually said awesome on the Propeller 2. I want that to be true. Lots of us do. I think it's going to rock hard on P2, and the size and capability of the P2 will make for a great fit. Features were added to the P2, at some significant expense mind you, just to make sure C has a great shot at the awesome.

    Going forward, we've all recognized the need for "standard" or "pro" type tools. It's been recognized by Parallax, and very significant efforts are underway to deliver those too. And Ross has done a perfectly fine job with Catalina. Not only do we have one C option, but two! And they are fine options!

    What else do you guys really need? How much is enough?

    Maybe if we make SPIN+PASM suck more, C might be more attractive?

    Nothing wrong with GAS, mind you. It's just not unified with SPIN, and that matters a lot. Ever wonder about the attractiveness of Apple computers? Same deal. They do the whole thing, and they do what it takes to optimize that experience, standard or not too. People pay a lot, sometimes double for the same basic hardware due to that value add, and people have paid a LOT over time to get at the same value associated with the Propeller, and for many of the same kinds of basic reasons.

    If "pro" or "standard" tools are needed, those really should be based off of OpenSpin.
    Leave the core SPIN+PASM as one unified thing. It can be put on chip for a self-hosted environment, it's great for knocking out quick projects, and it's fun as all get out too. Among many other things, like when we get to inline, it will be a simple, lean, common sense syntax that will just work and do the obvious things in the obvious ways...

    Just understanding the discussion about how to inline in C takes more time than it took to get going on SPIN+PASM. Same goes for gcc and friends too, and that says a lot.

    What it says most is that "pro" or "standard" tools have a lot of options needed for bigger projects, code reuse, integration into other tool chains, and so forth. We need that stuff. None of my comments should be taken as a negative about C and friends, or that we don't need it, etc...

    It's not about that at all.

    It is all about making sure we get the benefit of one unified design, just like we had with P1.

    Like I said, the idea that we need to kill off the excellent SPIN+PASM environment is offensive really. If the one we should have had needs to be written, so be it. Seriously.

    What we will and should have is the choices people need to maximize their use of the Propeller chip. That's what we should have.

    Let's preserve the awesome, not break it.


    Roy has it right. Let's get the core environment done, and likely see Chip port it to the P2 chip for a self-hosted environment. He's gonna get help doing that, because people want that. Done. Once that is done, it's gonna be mostly done and that's because the whole thing is simple to begin with. Lean.

    Once Roy gets OpenSpin done, all the C and other HLL efforts can build off of that. And instead of breaking something pretty great, we can author tools to help people, who want to reuse or contribute to reuse, and get that done in ways they find productive and useful.

    From there it's center of gravity and here's another basic thing to consider: What Chip did rocks hard. Those of us that like it, grok it, really like it for reasons already given. If all those standard, pro tools really can't compete reasonably, it seems to me that's a problem with those tools, not SPIN+PASM.

    Good grief!

    There won't be a common foundation because the use cases and motivations are orthoginal. I suppose there might be just one foundation if it gets ugly enough, and then a bunch of people just go away. Unified community at that point. Nice thoughts huh? I sure don't want to think 'em.

    And I'll put it another way. When I'm on the free gig, having a good time, learning stuff, building stuff I want to build, you know enjoying how Parallax "powers your genius", SPIN+PASM makes a lot of sense a lot of the time. And it makes sense because of how it was made and why it was made too.

    Pay me, and I'll be perfectly happy to deal with the standard, pro tools and write reusable code for you all the time. See how that works?
  • RossHRossH Posts: 4,696
    edited 2014-03-20 21:38
    potatohead wrote: »
    That's because SPIN + PASM is one unified thing. And doing that is part of the magic which brought many of us here. To be honest, I find the idea of breaking it offensive.

    No-one is advocating breaking SPIN + PASM. But neither SPIN nor PASM are usable on the P2 in their current form - so change in this space is both inevitable and necessary.

    All I am saying (and I believe Heater is thinking the same way) is that by extending PASM slightly, it can be used not only in SPIN + PASM, but also in C + PASM, BASIC + PASM, FORTH + PASM, etc etc - or just as plain old PASM!

    What's not to like about that? It doesn't undermine SPIN at all, as far as I can see.

    I don't really understand why this should be such a controversial issue.

    Ross.
  • Cluso99Cluso99 Posts: 17,708
    edited 2014-03-20 22:04
    Here is the latest P2 Instruction Summary
    Propeller II Instructions as of 2014/03/20
    ----------------------------------------------------------------------------------------------------------------------------
    ZCxS Opcode  ZC I Cond  Dest       Source     Instr00 01      10      11        Operand(s)                       Flags
    ----------------------------------------------------------------------------------------------------------------------------
    ZCWS 00000ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  RDBYTE  RDBYTEC RDWORD  RDWORDC   D,S/PTRA/PTRB                            ZC ZC ZC ZC 
    ZCWS 00001ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  RDLONG  RDLONGC RDAUX   RDAUXR    D,S/PTRA/PTRB || D,S/#0..$FF/PTRX/PTRY   ZC ZC ZC ZC 
    ZCMS 00010ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  ISOB    NOTB    CLRB    SETB      D,S/#                                    ZC ZC ZC ZC 
    ZCMS 00011ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  SETBC   SETBNC  SETBZ   SETBNZ    D,S/#                                    ZC ZC ZC ZC 
    ZCMS 00100ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  ANDN    AND     OR      XOR       D,S/#                                    ZC ZC ZC ZC 
    ZCMS 00101ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  MUXC    MUXNC   MUXZ    MUXNZ     D,S/#                                    ZC ZC ZC ZC 
    ZCMS 00110ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  ROR     ROL     SHR     SHL       D,S/#                                    ZC ZC ZC ZC 
    ZCMS 00111ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  RCR     RCL     SAR     REV       D,S/#                                    ZC ZC ZC ZC 
    ZCWS 01000ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  MOV     NOT     ABS     NEG       D,S/#                                    ZC ZC ZC ZC 
    ZCWS 01001ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  NEGC    NEGNC   NEGZ    NEGNZ     D,S/#                                    ZC ZC ZC ZC 
    ZCMS 01010ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  ADD     SUB     ADDX    SUBX      D,S/#                                    ZC ZC ZC ZC 
    ZCMS 01011ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  ADDS    SUBS    ADDSX   SUBSX     D,S/#                                    ZC ZC ZC ZC 
    ZCMS 01100ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  SUMC    SUMNC   SUMZ    SUMNZ     D,S/#                                    ZC ZC ZC ZC 
    ZCMS 01101ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  MIN     MAX     MINS    MAXS      D,S/#                                    ZC ZC ZC ZC 
    ZCMS 01110ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  ADDABS  SUBABS  INCMOD  DECMOD    D,S/#                                    ZC ZC ZC ZC 
    ZCMS 01111ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  CMPSUB  SUBR    MUL     SCL       D,S/#                                    ZC ZC ZC ZC 
    ZCWS 10000ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  DECOD2  DECOD3  DECOD4  DECOD5    D,S/#                                    ZC ZC ZC ZC 
    ----------------------------------------------------------------------------------------------------------------------------
    Z-WS 1000100 Zf I CCCC  DDDDDDDDD  SSSSSSSSS  BLSIZE  BLMASK                    D,S/#                                    Z- Z-       
    Z-WS 1000101 Zf I CCCC  DDDDDDDDD  SSSSSSSSS  ONECNT  ZERCNT                    D,S/#                                    Z- Z-       
    ZCWS 1000110 fC I CCCC  DDDDDDDDD  SSSSSSSSS  TOPONE          TOPZER            D,S/#                                    -C    -C    
    ZCWS 1000111 fC I CCCC  DDDDDDDDD  SSSSSSSSS  BOTONE          BOTZER            D,S/# | D,S/#,#0..7                      -C    --    
    --MS 10010nn nf I CCCC  DDDDDDDDD  SSSSSSSSS  GETNIB  SETNIB                    D,S/#,#0..7                              -- --       
    --MS 1001100 nf I CCCC  DDDDDDDDD  SSSSSSSSS  GETWORD SETWORD                   D,S/#,#0..1                              -- --       
    --MS 1001101 ff I CCCC  DDDDDDDDD  SSSSSSSSS  ROLNIB  ROLBYTE ROLWORD SETS      D,S/#                                    -- -- -- -- 
    --MS 1001110 ff I CCCC  DDDDDDDDD  SSSSSSSSS  SETD    SETCOND SETINST THALT     D,S/#                                    -- -- -- -- 
    -CMS 1001111 0C I CCCC  DDDDDDDDD  SSSSSSSSS  WAITCNT                           D,S/#                                    -C          
    --MS 1001111 10 I CCCC  DDDDDDDDD  SSSSSSSSS  <empty> PICKZC                    D,S/#                                    -- --       
    --MS 101000n nf I CCCC  DDDDDDDDD  SSSSSSSSS  GETBYTE SETBYTE                   D,S/#,#0..3                              -- --       
    --WS 1010010 ff I CCCC  DDDDDDDDD  SSSSSSSSS  SETBYTS MOVBYTS PACKRGB UNPKRGB   D,S/#                                    -- -- -- -- 
    --MS 1010011 ff I CCCC  DDDDDDDDD  SSSSSSSSS  ADDPIX  MULPIX  BLNPIX  MIXPIX    D,S/#                                    -- -- -- -- 
    ZCMS 1010100 ZC I CCCC  DDDDDDDDD  SSSSSSSSS  JMPSW                             D,S/@                                    ZC          
    ZCMS 1010101 ZC I CCCC  DDDDDDDDD  SSSSSSSSS  JMPSWD                            D,S/@                                    ZC          
    --MS 1010110 ff I CCCC  DDDDDDDDD  SSSSSSSSS  DJZ     DJZD    DJNZ    DJNZD     D,S/@                                    -- -- -- -- 
    --RS 1010111 ff I CCCC  DDDDDDDDD  SSSSSSSSS  JZ      JZD     JNZ     JNZD      D,S/@                                    -- -- -- -- 
    ZCRS 10110ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  TESTB   TESTN   TEST    CMP       D,S/#                                    ZC ZC ZC ZC 
    ZCRS 10111ff ZC I CCCC  DDDDDDDDD  SSSSSSSSS  CMPX    CMPS    CMPSX   CMPR      D,S/#                                    ZC ZC ZC ZC 
    -CRS 11000fn nC I CCCC  DDDDDDDDD  SSSSSSSSS  WAITPEQ WAITPNE                   D,S/#,#0..3                              -C -C       
    ---S 110010f nn I CCCC  nnnnnnnnn  SSSSSSSSS  WAITVID WAITVID                   #0..$DFF,S/# | D,S/#                     -- --       
    --LS 110011f fL I CCCC  DDDDDDDDD  SSSSSSSSS  WRBYTE  WRWORD  WRLONG  WRWIDEM   D/#,S/PTRA/PTRB                          -- -- -- -- 
    --LS 110100f fL I CCCC  DDDDDDDDD  SSSSSSSSS  WRAUX   WRAUXR  SETACCA SETACCB   D/#,S/#0..$FF/PTRX/PTRY || D/#,S/#       -- -- -- -- 
    --LS 110101f fL I CCCC  DDDDDDDDD  SSSSSSSSS  MACA    MACB    MUL32   MUL32U    D/#,S/#                                  -- -- -- -- 
    --LS 110110f fL I CCCC  DDDDDDDDD  SSSSSSSSS  DIV32   DIV32U  DIV64   DIV64U    D/#,S/#                                  -- -- -- -- 
    --LS 110111f fL I CCCC  DDDDDDDDD  SSSSSSSSS  SQRT64  QSINCOS QARCTAN QROTATE   D/#,S/#                                  -- -- -- -- 
    --LS 111000n nL I CCCC  DDDDDDDDD  SSSSSSSSS  CFGPINS cfgpins cfgpins SETMAP    D/#,S/#,#0..2 ||| D/#,S/#                -- -- -- -- 
    --LS 111001f fL I CCCC  DDDDDDDDD  SSSSSSSSS  SETSERA SETSERB SETCTRS SETWAVS   D/#,S/#                                  -- -- -- -- 
    --LS 111010f fL I CCCC  DDDDDDDDD  SSSSSSSSS  SETFRQS SETPHSS ADDPHSS SUBPHSS   D/#,S/#                                  -- -- -- -- 
    --LS 111011f fL I CCCC  DDDDDDDDD  SSSSSSSSS  SETXFR  SETMIX  COGRUN  COGRUNX   D/#,S/#                                  -- -- -- -- 
    --LS 111100f fL I CCCC  DDDDDDDDD  SSSSSSSSS  FRAC    LODINDS CIRINDA CIRINDB   D/#,S/#                                  -- -- -- -- 
    --LS 111101f fL I CCCC  DDDDDDDDD  SSSSSSSSS  JP      JPD     JNP     JNPD      D/#,S/@                                  -- -- -- -- 
    --WS 111110f ff I CCCC  DDDDDDDDD  SSSSSSSSS  LOCBASE LOCBYTE LOCWORD LOCLONG   D,S/@                                    -- -- -- -- 
    --W- 1111101 00 f CCCC  DDDDDDDDD  sssssssss  LOCINST JMPLIST                   D,@s                                     -- --       
    ---- 1111101 01 0 BBAA  ddddddddd  sssssssss  FIXINDA                           FIX/SET #s|#d|#d,#s                      --          
    ---- 1111101 01 1 nnnn  nnnnnnnnn  nnniiiiii  REPS                              #1..$10000,#1..64                        --          
    ---- 1111101 1f n nnnn  nnnnnnnnn  nnnnnnnnn  AUGS    AUGD                      #23bits                                  -- --       
    ---- 1111110 00 0 CCCC  ff nnnnnn  nnnnnnnnn  LOCPTRA LOCPTRA LOCPTRB LOCPTRB   #abs | @rel | #abs | @rel                -- -- -- -- 
    ---- 1111110 00 1 CCCC  ff nnnnnn  nnnnnnnnn  JMP     JMP     JMPD    JMPD      #abs | @rel | #abs | @rel                -- -- -- -- 
    ---- 1111110 01 0 CCCC  ff nnnnnn  nnnnnnnnn  LINK    LINK    LINKD   LINKD     {0} #abs | {0} @rel | {0} #abs | {0} @re -- -- -- -- 
    ---- 1111110 01 1 CCCC  ff nnnnnn  nnnnnnnnn  CALL    CALL    CALLD   CALLD     #abs | @rel | #abs | @rel                -- -- -- -- 
    ---- 1111110 10 0 CCCC  ff nnnnnn  nnnnnnnnn  CALLA   CALLA   CALLAD  CALLAD    #abs | @rel | #abs | @rel                -- -- -- -- 
    ---- 1111110 10 1 CCCC  ff nnnnnn  nnnnnnnnn  CALLB   CALLB   CALLBD  CALLBD    #abs | @rel | #abs | @rel                -- -- -- -- 
    ---- 1111110 11 0 CCCC  ff nnnnnn  nnnnnnnnn  CALLX   CALLX   CALLXD  CALLXD    #abs | @rel | #abs | @rel                -- -- -- -- 
    ---- 1111110 11 1 CCCC  ff nnnnnn  nnnnnnnnn  CALLY   CALLY   CALLYD  CALLYD    #abs | @rel | #abs | @rel                -- -- -- -- 
    ----------------------------------------------------------------------------------------------------------------------------
    ZCW- 1111111 ZC 0 CCCC  DDDDDDDDD  0000000ff  COGID   TASKID  LOCKNEW GETLFSR   D                                        ZC ZC ZC ZC 
    ZCW- 1111111 ZC 0 CCCC  DDDDDDDDD  0000001ff  GETCNT  GETCNTX GETACAL GETACAH   D                                        ZC ZC ZC ZC 
    ZCW- 1111111 ZC 0 CCCC  DDDDDDDDD  0000010ff  GETACBL GETACBH GETPTRA GETPTRB   D                                        ZC ZC ZC ZC 
    ZCW- 1111111 ZC 0 CCCC  DDDDDDDDD  0000011ff  GETPTRX GETPTRY SERINA  SERINB    D                                        ZC ZC ZC ZC 
    ZCW- 1111111 ZC 0 CCCC  DDDDDDDDD  0000100ff  GETMULL GETMULH GETDIVQ GETDIVR   D                                        ZC ZC ZC ZC 
    ZCW- 1111111 ZC 0 CCCC  DDDDDDDDD  0000101ff  GETSQRT GETQX   GETQY   GETQZ     D                                        ZC ZC ZC ZC 
    ZCW- 1111111 ZC 0 CCCC  DDDDDDDDD  0000110ff  GETPHSA GETPHZA GETCOSA GETSINA   D                                        ZC ZC ZC ZC 
    ZCW- 1111111 ZC 0 CCCC  DDDDDDDDD  0000111ff  GETPHSB GETPHZB GETCOSB GETSINB   D                                        ZC ZC ZC ZC 
    ZCM- 1111111 ZC 0 CCCC  DDDDDDDDD  0001000ff  PUSHZC  POPZC   SUBCNT  GETPIX    D                                        ZC ZC ZC ZC 
    ZCM- 1111111 ZC 0 CCCC  DDDDDDDDD  0001001ff  BINBCD  BCDBIN  BINGRY  GRYBIN    D                                        ZC ZC ZC ZC 
    ZCM- 1111111 ZC 0 CCCC  DDDDDDDDD  0001010ff  ESWAP4  ESWAP8  SEUSSF  SEUSSR    D                                        ZC ZC ZC ZC 
    ZCM- 1111111 ZC 0 CCCC  DDDDDDDDD  0001011ff  SPLITB  MERGEB  SPLITW  MERGEW    D                                        ZC ZC ZC ZC 
    ZCM- 1111111 ZC 0 CCCC  DDDDDDDDD  0001100ff  CHKDEC  CHKHEX  CHKLET  CHKSYM    D                                        ZC ZC ZC ZC 
    ZCM- 1111111 ZC 0 CCCC  DDDDDDDDD  0001101ff  INCD    DECD    INCDS   DECDS     D                                        ZC ZC ZC ZC 
    ZCW- 1111111 ZC 0 CCCC  DDDDDDDDD  0001110ff  POPT0   POPT1   POPT2   POPT3     D                                        ZC ZC ZC ZC 
    ZCW- 1111111 ZC 0 CCCC  DDDDDDDDD  0001111ff  POP     <empty> INCPAT  DECPAT    D                                        ZC ZC ZC ZC 
    ----------------------------------------------------------------------------------------------------------------------------
    --L- 1111111 00 L CCCC  DDDDDDDDD  0100000ff  CLKSET  COGSTOP LOCKSET LOCKCLR   D/#                                      -- -- -C -C 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0100001ff  LOCKRET RDWIDE  RDWIDEC RDWIDEQ   D/# | D/PTRA/PTRB                        -- -- -- -- 
    ZCL- 1111111 ZC L CCCC  DDDDDDDDD  0100010ff  GETP    GETNP   SEROUTA SEROUTB   D/#                                      ZC ZC -C -C 
    -CL- 1111111 0C L CCCC  DDDDDDDDD  0100011ff  CMPCNT  WAITPX  WAITPR  WAITPF    D/#                                      -C -C -C -C 
    --L- 1111111 ZC L CCCC  DDDDDDDDD  0100100ff  COGNEW  COGNEWX SETXCH  SETTASK   {D} D/# || D/#                           ZC ZC -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0100101ff  SETRACE SARACCA SARACCB SARACCS   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0100110ff  SETPTRA SETPTRB ADDPTRA ADDPTRB   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0100111ff  SUBPTRA SUBPTRB SETWIDE SETWIDZ   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0101000ff  SETPTRX SETPTRY ADDPTRX ADDPTRY   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0101001ff  SUBPTRX SUBPTRY PASSCNT WAIT      D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0101010ff  OFFP    NOTP    CLRP    SETP      D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0101011ff  SETPC   SETPNC  SETPZ   SETPNZ    D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0101100ff  DIV64D  SQRT32  QLOG    QEXP      D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0101101ff  SETQI   SETQZ   CFGDACS SETDACS   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0101110ff  CFGDAC0 CFGDAC1 CFGDAC2 CFGDAC3   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0101111ff  SETDAC0 SETDAC1 SETDAC2 SETDAC3   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0110000ff  SETCTRA SETWAVA SETFRQA SETPHSA   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0110001ff  ADDPHSA SUBPHSA SETVID  SETVIDY   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0110010ff  SETCTRB SETWAVB SETFRQB SETPHSB   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0110011ff  ADDPHSB SUBPHSB SETVIDI SETVIDQ   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0110100ff  SETPIX  SETPIXZ SETPIXU SETPIXV   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0110101ff  SETPIXA SETPIXR SETPIXG SETPIXB   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0110110ff  SETPORA SETPORB SETPORC SETPORD   D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0110111ff  RDWIDEA RDWIDEB WRWIDEA WRWIDEB   D/#1..512                                -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0111000ff  TARGOFF TARG    TARGP   TARGN     D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0111001ff  targoff TARGX   TARGPX  TARGNX    D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0111010ff  JMPT0   JMPT1   JMPT2   JMPT3     D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0111011ff  PUSHT0  PUSHT1  PUSHT2  PUSHT3    D/#                                      -- -- -- -- 
    --L- 1111111 00 L CCCC  DDDDDDDDD  0111100ff  PUSH    SETZC   SETLFSR           D/#                                      -- ZC --    
    ----------------------------------------------------------------------------------------------------------------------------
    --R- 1111111 00 x CCCC  DDDDDDDDD  1000000ff  LOCPTRA LOCPTRB JMP     JMPD      D                                        -- -- ZC ZC 
    --R- 1111111 ZC x CCCC  DDDDDDDDD  1000001ff  LINK    LINKD   CALL    CALLD     {0} D || D                               ZC ZC ZC ZC 
    --R- 1111111 ZC x CCCC  DDDDDDDDD  1000010ff  CALLA   CALLAD  CALLB   CALLBD    D                                        ZC ZC ZC ZC 
    --R- 1111111 ZC x CCCC  DDDDDDDDD  1000011ff  CALLX   CALLXD  CALLY   CALLYD    D                                        ZC ZC ZC ZC 
    --R- 1111111 00 x CCCC  DDDDDDDDD  1000100ff  LODINDA LODINDB                   D                                        -- --       
    ----------------------------------------------------------------------------------------------------------------------------
    ZC-- 1111111 ZC x CCCC  xxxxxxxxx  1100000ff  RETA    RETAD   RETB    RETBD                                              ZC ZC ZC ZC 
    ZC-- 1111111 ZC x CCCC  xxxxxxxxx  1100001ff  RETX    RETXD   RETY    RETYD                                              ZC ZC ZC ZC 
    ZC-- 1111111 ZC x CCCC  xxxxxxxxx  1100010ff  RET     RETD    POLCTRA POLCTRB                                            ZC ZC ZC ZC 
    ZC-- 1111111 ZC x CCCC  xxxxxxxxx  1100011ff  POLVID  CAPCTRA CAPCTRB CAPCTRS                                            ZC -- -- -- 
    ---- 1111111 00 x CCCC  xxxxxxxxx  1100100ff  SETPIXW CLRACCA CLRACCB CLRACCS                                            -- -- -- -- 
    ZC-- 1111111 ZC x CCCC  xxxxxxxxx  1100101ff  CHKPTRX CHKPTRY SYNCTRA SYNCTRB                                            ZC ZC -- -- 
    ---- 1111111 00 x CCCC  xxxxxxxxx  1100110ff  DCACHEX ICACHEX ICACHEP ICACHEN                                            -- -- -- -- 
    ---- 1111111 00 x 0000  xxxxxxxxx  1100111ff  TLOCK   TFREE   LOADT3  SAVET3                                             -- -- -- -- 
    ---- 1111111 00 x 0000  xxxxxxxxx  1101000ff  TARGOFF TARG    TARGP   TARGN                                              -- -- -- -- 
    ---- 1111111 00 x 0000  xxxxxxxxx  1101001ff  targoff TARGX   TARGPX  TARGNX                                             -- -- -- -- 
    ---- 1111111 00 x 0000  xxxxxxxxx  1101010ff  PASSTXA PASSTXB <empty> <empty>                                            -- -- -- -- 
    ----------------------------------------------------------------------------------------------------------------------------
    ---- 0000000 00 0 0000  000000000  000000000  NOP                                                                        --          
    ----------------------------------------------------------------------------------------------------------------------------
    
    InstructionSummary_20140320.spin
  • Heater.Heater. Posts: 21,233
    edited 2014-03-20 22:23
    potatohead,

    I'm totally with you. I love Spin for all the reasons you sited. It's simple and quick to get started with, especially for non-expreience programmers. Having integerated PASM makes transitioning to assembler a doddle. The PASM syntax and P1 architecture are the simplest nicest assembly language programming environment I have ever seen. And so on.

    I am not advocating breaking Spin/PASM, especially not for the P1.

    So imagine the PII is out for two years and there are now a couple of hundred objects with assembly language drivers in the OBEX and floating around the forum. tens of thousands of man hours of work will have gone into creating them. They will have been written in both Spin and C.

    Problem is those juicy assembler language drivers, are not usable between languages. Which seems kind of crazy and wasteful. Getting such code into peoples hands easily is what the Propeller ecosystem thrives on. It should be made friction free.

    That is the problem we are discussing here. Perhaps you do not feel that is a problem.

    One solution is my proposal for breaking the linkage between PASM and Spin by introducing the "PASM" section and a few simple rules around it. I don't believe this is a big hardship for Spin users. Most new users would probably accept the new syntax and not even notice the semantic differences.

    Another solution is Roy's answer, get the tools to do the work. Open spin may be able to expose what linkage there is between PASM and Spin in such a way that C programmers could easily use the PASM binaries extracted from Spin objects.

    Does that solution help going the other way? Assembler language drivers written by C programmers migrating to Spin programs ?

    My feeling is that the "no-linkage" binary blob approach is the most universal way.

    These ideas are worthy of more exploration. Or do we just let the problem persist into the PII world?
  • potatoheadpotatohead Posts: 10,179
    edited 2014-03-20 22:32
    Thanks Cluso.
  • cgraceycgracey Posts: 13,574
    edited 2014-03-20 22:54
    I really want to make my own tools function holistically with the hardware, without a bunch of stifling accommodations made for other paradigms.

    However, I'm sure a mode of writing Spin and PASM code could be formalized, as has already been brought up here, that would enable inter-operability with C.
  • Heater.Heater. Posts: 21,233
    edited 2014-03-20 23:03
    Chip,

    I totally agree. No stifling for me. I'm stifled enough already.

    But there we have a contradiction, yes a mode of writing Spin and PASM code could be formalized, it would also be totally ignored by those "unstifled" programmers who don't know and/or care why there is such a formalism. We can almost be sure this will happen as such a formalism has been discussed on the P1 forum for years and even documented by RossH. It has all been ignored.

    Would the introduction of a "PASM" section be stifling? Or just a neat way to organize code in the spirit of the Spin language?
  • RossHRossH Posts: 4,696
    edited 2014-03-20 23:39
    cgracey wrote: »
    I really want to make my own tools function holistically with the hardware, without a bunch of stifling accommodations made for other paradigms.
    Perfectly understandable. I feel the same way myself. :smile:
    cgracey wrote: »
    However, I'm sure a mode of writing Spin and PASM code could be formalized, as has already been brought up here, that would enable inter-operability with C.
    Yes, I think so too. But what Heater and I are proposing here is something even simpler - essentially, just "loosening" the tight coupling between SPIN and PASM, to facilitate using PASM either by itself, or in conjunction with languages other than SPIN.

    It is already possible to do this - but so difficult that few bother to do so.

    Ross.
  • cgraceycgracey Posts: 13,574
    edited 2014-03-20 23:50
    RossH wrote: »
    Perfectly understandable. I feel the same way myself. :smile:

    Yes, I think so too. But what Heater and I are proposing here is something even simpler - essentially, just "loosening" the tight coupling between SPIN and PASM, to facilitate using PASM either by itself, or in conjunction with languages other than SPIN.

    It is already possible to do this - but so difficult that few bother to do so.

    Ross.


    But that difficulty is what makes it not so appealing, isn't it?

    I know you listed a few things that would have to be done. Would you mind listing them here (again) so that they could be contemplated? I know this stuff exists in another post, or posts. The simpler you can keep the guidelines, the better we can think about it.
  • Heater.Heater. Posts: 21,233
    edited 2014-03-21 00:09
    I think that to enable Spin programmers to create PASM code that is usable outside of Spin, with C say, would require only slight modification to the Spin language:

    1) Introduce a PASM section. This is basically a DAT section with some extra rules...

    2) Any PASM code to be launched into a COG has to be in a PASM section.

    3) Code in a PASM section cannot access any variables defined in Spin, VAR blocks or DAT sections, by name. This removes dependency of PASM from Spin data layout.

    4) Spin code cannot write any locations in a PASM section, at least by name. This prevents initializing of LONGs and such prior to loading to COG. Data that C or other languages would not know about.

    5) Due to 4) all parameters passed to PASM prior to launch go through pointers passed via PAR.

    6) All communication between a running PASM code and Spin go through shared HUB as normal, using pointers passed through PAR.

    The basic idea is to decouple the PASM and Spin. Then the PASM can be compiled and extracted as a usable "binary blob" or "firmware" by openspin or BST etc and used in other language systems.

    This is not to onerous is it? It's even good practice, makes for nice clean code. In the same way a Spin object cannot see a sub-objects variables or PRI's.

    Note: This works both ways. Such "binary blobs" created by C or whatever can be used in Spin by including them via a file statement. It's a win-win.

  • potatoheadpotatohead Posts: 10,179
    edited 2014-03-21 00:23
    I think that to enable Spin programmers to create PASM code that is usable outside of Spin

    You mean force right?
  • Heater.Heater. Posts: 21,233
    edited 2014-03-21 00:26
    potatoehead,


    Yes discussions in the past got overly complex what with mailboxes, registries, etc. What is proposed here though is dead simple.


    RossH has indeed converted drivers, he is not all talk. Others have done so as well. Even I adapted a couple of drivers back in the Zog C days. We don't want to do that again, and again, and again.


    I also really don't want PASM and SPIN separate. That is not what is being proposed here.


    Gas has nothing to do with this. It's not in the picture. That's for the C guys to suffer :)


    The nice expressive DAT section can remain. The proposed PASM section is a DAT section, all the same expressive cool ways to express data remain in there.
  • RossHRossH Posts: 4,696
    edited 2014-03-21 00:48
    cgracey wrote: »
    But that difficulty is what makes it not so appealing, isn't it?

    I know you listed a few things that would have to be done. Would you mind listing them here (again) so that they could be contemplated? I know this stuff exists in another post, or posts. The simpler you can keep the guidelines, the better we can think about it.

    Getting over most of the difficulties and complexities could be done with a few simple conventions, plus a few simple changes or extensions to SPIN/PASM. For instance (this is just the first one that springs to mind) - why does a Spin object have to have at least one PUB segment to compile? All this does is force you to include a dummy method, which generates code that has to later be stripped out when all you want is the compiled PASM.

    Heater has already summarized some of the conventions. I'll try and put a few more together this weekend and post them for wider discussion. I'd suggest we start a new thread (perhaps Heater would like to do so, since he started the discussion) so as not to clutter this one unduly.

    Ross.
  • msrobotsmsrobots Posts: 3,344
    edited 2014-03-21 00:52
    Guys, I think you all are missing something.

    The whole idea of a binary blob for PASM is obsolete. We have HUBEXEC now.

    Does anyone here really want to tell me that my hubexec PASM code is not allowed to see my labels in HUB?

    Honestly. This is HUMBUG.

    Enjoy!

    Mike
  • RossHRossH Posts: 4,696
    edited 2014-03-21 01:00
    potatohead wrote: »
    You mean force right?

    No, of course not. If you are creating PASM objects that are only intended to operate withing your own SPIN program, or with other SPIN programs, you are free to use whatever conventions you want - and the interface to such objects is generally a set of SPIN methods anyway, with the PASM code nicely encapsulated.

    But sometimes you just want to submit a chunk of generally useful PASM code, exposing some other interface - and there is currently no way to do so. You have to wrap it in SPIN because that is currently the only accepted convention - we have no convention to enable that code to be called from any cog, unless that cog is running SPIN. This has nothing to do with C - this code cannot even be called from another cog within the same SPIN program that is running PASM!

    Ross.
  • potatoheadpotatohead Posts: 10,179
    edited 2014-03-21 07:57
    For that to be true Ross, we would need to ADD this PASM section and have the rules apply there, but not actually change how DAT works today.

    I'm in favor of doing that. Maybe we should just call the new section BLOB. And I'm serious! Leave SPIN as is today and add BLOB to the list of section definitions and behaviors. In the BLOB section, do these reuse things so that we make sure a BLOB works well. That's a good thing!

    This:
    The whole idea of a binary blob for PASM is obsolete. We have HUBEXEC now.

    Does anyone here really want to tell me that my hubexec PASM code is not allowed to see my labels in HUB?

    Honestly. This is HUMBUG.

    Is true and precisely why DAT and how SPIN+PASM works right now needs to be left alone. A lot of things will be possible, and yes not all that easy to reuse, but again, that's not always the primary case. Frankly, I think Chip has already seen this in that Pnut doesn't currently require any SPIN at all to build. It can assemble only.

    Adding BLOB would provide for that intent, and we could very easily publish a lot of good stuff for people to use in the BLOB section when they have the intent to publish for reuse, or where people do conversions. Since the result is MIT, if published for sharing here in the traditional way we've done, doing that stuff is not only encouraged, but expected.

    Re: Not all talk.

    Heater, of course! Ross has done a fine job as have others. I'm sorry I implied otherwise. Wasn't my intent.

    Re: No other convention.

    Right now, Pnut works without having a PUB of any kind. Pretty easy to have that continue. And it's got SPIN 2 in there, but it's early and kind of broken at the moment too.

    We can make a nice BLOB on P2 right now. If that isn't changed, would it not work for this purpose? One could use DAT in whatever way makes sense, and if Chip sees the core rules for a BLOB section and implements them, wouldn't that more or less reach the goals everyone has here?

    Perhaps this discussion is really early, save for the idea of the BLOB section specifically intended for reuse, both directions even. If we do that, we could then package up something in C and bring it over. All good.

    Adding something to SPIN for this purpose is good. We need it. Preventing things isn't something I'm a fan of, for reasons already given.

    msrobots is right about it too. With HUBEX, making PASM BLOBS is not always going to happen now. And the unified SPIN+PASM is perfect for how HUBEX will end up working. Which, by the way, is precisely why I'm vocal about this right now.

    And that means making a BLOB is something people will have a specific intent to do, which makes an addition aimed at making that happen nicely perfectly sensible.

    Seriously, how about we work to define BLOB so that it's a total win for the reuse case? Split the middle, so to speak.
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-03-21 08:10
    +1

    I like the BLOB way

    Suggestion:
    CON ' for the BLOB
    
    ...
    
    BLOB ' just like DAT, but enforces certain rules... ie no access to labels outside of this BLOB section, but exports 'par' and 'start' as long aligned hub addresses
    
    par      LONG ....
    
    ' more parameters, each with a label
    ' BLOB could export:
    ' - a .h with a struct for C/C++ for accessing the parameters
    ' - a .spin automatically generated interface (would be nice if Spin supported struct's)
    
    start    ' where the cog entry point is
    

    I think that is all we really need.

    It could export an object file, with the first long encoding relative par&start in the fashion COGRUN/COGRUNX needs.

    NOTE:

    Normal current expected Spin/Pasm would not change at all.

    Suggestion:

    New Obex category - BLOBS
  • SapiehaSapieha Posts: 2,964
    edited 2014-03-21 08:26
    Hi All.

    I don't know what any of You need possibility of ASSEMBLE without invoke SPIN part.

    BUT I need that to that type of programing.
    ' Portable Low Type Driver
    ' I don't know what You will call it.
    
    DAT
                orgh @XXX
    DriveTable
                jmp    @Init
                jmp    @SD_read_sector
                jmp    @SD_read_Dir
                jmp    @SD_write_sector
                jmp    @SD_write_Dir
            
                ......... and so on
                ret ...... end table
    Init            
                xxx    xxx,xxx
                ret
    SD_read_sector        
                xxx    xxx,xxx
                ret
    SD_read_Dir
                xxx    xxx,xxx
                ret
    SD_write_sector
                xxx    xxx,xxx
                ret
    SD_write_Dir
                xxx    xxx,xxx
                ret
    
    
    
  • potatoheadpotatohead Posts: 10,179
    edited 2014-03-21 08:28
    And BLOB is actually the right technical term, which I have always found hilarious! Binary, Loadable, OBject. Perfect for our intent here.
  • Heater.Heater. Posts: 21,233
    edited 2014-03-21 09:02
    potatohead,

    Nope,

    BLOB = Binary Large Object
    or
    BLOB = Blitter Object

    http://www.acronymfinder.com/BLOB.html
    http://en.wikipedia.org/wiki/Binary_large_object

    However I think BLOB is actually a better name for that new Spin section than my suggested PASM.

    Why, because PII will have inline PASM and hub exec PASM which I don't think should be included in this scheme.
  • potatoheadpotatohead Posts: 10,179
    edited 2014-03-21 09:13
    Yes, I haveseen those definitions too, as well as the one I put here. Binary lerge is the most "official" one to me, and it was the first...

    Parallax would not be the first one to reference loadable... Like you say, it's a good fit anyway.
  • potatoheadpotatohead Posts: 10,179
    edited 2014-03-21 09:29
    BTW, when I say leave SPIN as it is today, I don't mean it literally. New things are needed for P2. We discussed object pointers, larger memory space, now BLOB, inline, tasks, etc...

    I mean the basic syntax and how DAT works.
  • dMajodMajo Posts: 837
    edited 2014-03-21 19:37
    Heater. wrote: »
    dMajo,

    You have hit the nail on the head.

    Almost...It's not the PropTool that was born to simple it was the Spin language itself. Spin + included PASM that is.

    The structure of which you speak, "spin in one side and pasm in other having a fixed interface" is not a function of the tool used for editing but the very language definition. Don't forget there are many other Spin compilers that do not depend on any GUI tool to use.

    Aside: I have noticed many times that users of IDE's, and especially VB, cannot tell the difference between a programming language and the tool they use to edit it.

    Now, about those rules or structure...

    I think that to get Spin programmers to create PASM code that is usable outside of Spin, with C say, would require only slight modification to the Spin language.

    1) Introduce a PASM section. This is basically a DAT section with some extra rules...

    2) Make it a requirement that any PASM code to be launched into a COG has to be in a PASM section.

    3) Code on a PASM section cannot access any variables defined in Spin VAR blocks or DAT sections by name. This removes dependency of PASM from Spin data layout.

    4) Spin code cannot access any locations in a PASM section, at least by name. This prevents initializing of LONGs and such prior to loading to COG. Data that C would not know about.

    5) Due to 4) all parameters passed to PASM prior to launch are to go through pointers passed in PAR.

    6) All communication between a running PASM code and Spin go through shared HUB as normal, using pointers passed through PAR.

    With this in place there is no symbolic linkage between PASM and Spin, except for the starting address which Spin needs. With no linkage the resulting code can be compiled buy tools such as openspin, or BST into a binary blob that is usable by any language.

    However, I suspect the Spin community would hate this idea.

    Heater, sorry ... I do not agree ... perhaps is due to my lack of knowledge.

    Take a class for example. I don' t want to introduce classes/istances as their real meaning, it is only an example of a file that exists in the ide, part of the project.
    In classes you declare properties, methods and these are exposed to other part of program. Classes on the development system are files on the filesystem, with a known structure, part of the project.
    Now if a pasm section instead of residing in dat will be a class (not in its real meaning, just in the way it is written) some longs can be properties. This mean they will be saved with a known structure. Spin can initialize these longs because they are exposed as properties. The same can happen for C.
    A pasm "class" can be imported in a spin project or in a c project.
    Perhaps you can even mix all. If you have a pasm class , a spin class a c class perhaps pasm and c can run natively while c-xmm and spin will be executed through their kernel/interpreter in a separate cog and they can communicate to each-other through the exposed properties, well known for everyone of them or better said well known for the ide that have to compile/link/assemble it with the right tools. Inside every single kind of class the rules will pretty remain the same for every single language. The only difference is that one class can be only written in one language.
    You can have a project choice (spin/pasm/c) that defines the primary application language. Than classes can be of any choice (spin/pasm/c/forth ...) and everything cooperates.

    Why can't this concept work?

    Now change the name, don't call it class ... it was to explain the idea with my poor english.
  • Cluso99Cluso99 Posts: 17,708
    edited 2014-03-22 05:49
    Come on guys... where are all the neat new P2 programs ??? You have had 24hours!

    I have been tiling and painting at my son's house all day :( so expected to be cheared up by some amazing discoveries ;););)
  • Cluso99Cluso99 Posts: 17,708
    edited 2014-03-22 06:16
    Now we have hubex mode, I was wondering if it might be nice to have a simple hook in the Rom Monitor to jmp/call a user monitor extension in hub.
    ozpropdev and I have both been working on p2 debuggers - different but complimentary. I expect theremay be others too later.

    What ifthey could be simply hooked (by a single command) into the monitor. This way our code could become extensions to the monitor.

    Thoughts ?
  • potatoheadpotatohead Posts: 10,179
    edited 2014-03-22 21:02
    I'm not opposed to it. Actually, maybe it's the right or a very good thing to do. :)

    Seems to me, having the monitor check the very first two longs or maybe even the first one of HUB RAM for a signature and address, a debug package could just be uploaded right through whatever terminal people use. Have it always check this when a command is entered that isn't one of it's own, and if the package is there, pass the current command and address to it, and the user is off to the races.

    The upload can be a file copy to the serial port, or a paste through the terminal. Either way, the package can specify those or that long, then any other addresses and data needed to place whatever extension makes sense, where it makes sense.

    Early on, I was making heavy use of the copy / paste function to upload lots of data, and it worked very well. The way addresses work is either one specifies an address with a line of data, or a colon ":" and that makes relocating things, or even just specifying where things go super easy. The package would specify the low address long, or longs, then specify a start address, all the data for the package, another start address, all the data, if desired, etc...

    A simple copy package.txt > COM8 gets it done! (documented in the monitor PDF, which I will update this time around)

    BTW, doing this wouldn't really require HUBEX mode. It's just simpler.

    Another thing: If that same check is always done in the monitor, a person who wants the integrated debugger can just include it, parking it at whatever address they feel makes sense given how their program works, then launch the monitor on a COG as part of their ordinary program startup too.

    One question: How would an extension understand multiple monitors could be running, and do we care?
  • pik33pik33 Posts: 1,014
    edited 2014-03-22 23:34
    Heater. wrote: »
    potatohead,

    Nope,

    BLOB = Binary Large Object
    or
    BLOB = Blitter Object

    http://www.acronymfinder.com/BLOB.html
    http://en.wikipedia.org/wiki/Binary_large_object

    However I think BLOB is actually a better name for that new Spin section than my suggested PASM.

    Why, because PII will have inline PASM and hub exec PASM which I don't think should be included in this scheme.

    Amiga blitter objects was called BOBs. :) and not BLOBs.
  • potatoheadpotatohead Posts: 10,179
    edited 2014-03-22 23:41
    Yep. They were. Noted!

    And this:
    Why, because PII will have inline PASM and hub exec PASM which I don't think should be included in this scheme.

    So long as the current function of DAT is unchanged, adding the BLOB scheme with the intent of helping to create reusable PASM is good. Otherwise, ALL PASM should remain as is in DAT, including that PASM targeted at a COG.
Sign In or Register to comment.