Shop Learn
ASM aliases for ALTx would be convenient. — Parallax Forums

ASM aliases for ALTx would be convenient.

pik33pik33 Posts: 1,226
edited 2022-01-15 10:59 in Propeller 2

Instead of addressing modes as in 6502 or 68000 we have ALTx instructions.

What if to add aliases for these instruction, like ## for long immediates?

This can make the code easier to read (and write)

Instead of

            altr base,#offset
            add a,b

            alts table,#1
            mov c,0-0

there may be

            add [base+offset],a,b
            mov c,table[1]

Let the compiler do the work instead of us and let these 0-0 disappear :)
And there is alti...

If I can understand, it enables things like

           add result++, source--

but we need to manually prepare its bitfield. So.. what if we can extend the asm syntax to do it for us?

Comments

  • TonyB_TonyB_ Posts: 1,809
    edited 2022-01-15 12:00

    This has been requested on the forum before. Syntax for 'hidden' ALTI instructions could be interesting.

  • evanhevanh Posts: 12,230

    Chip might have more time for these suggestions now. He appears to be back on the forums again.

  • cgraceycgracey Posts: 13,690

    I agree these would help us write code more easily. You have to get your mind into granny gear to do any of this right now, so it's painful. It's probably causing these features to be under-utilized.

    We'd need to list out all the permutations that would be common.

  • I feel like obscuring the nature of ALTx may be somewhat harmful. If it just looks like an addressing mode, you maybe wouldn't realize that using it repeatedly doubles the time and size the code requires and that it can be used in creative ways.

    Then again, I don't really have a problem with ALTD/ALTS/ALTR. I do keep forgetting what the ALTS bits do though.


    Addendum: some creative uses of ALTx in my recent memory

    You can use it on immediates, for example to subtract one without altering the variable:

    altd  COUNT_, #511\n
    setq #0-0\n
    wrlong local01, ptra++\n
    

    When writing code to be SKIPF'd, you can skip just the ALTx to let the original D/S through:

            _ret_ setword zk_debc,zk_tmp16,#0 ' set BC
            _ret_ setword zk_debc,zk_tmp16,#1 ' set DE
                  altd zk_hlptr
            _ret_ setword zk_sp,zk_tmp16,#0   ' set SP/HL/I*
    
  • evanhevanh Posts: 12,230
    edited 2022-01-16 04:44

    I'll start with classifying the addressing modes:

    • Instruction immediate - Data value is encoded into the instruction. Syntax: #number. AUGmented above #511.
    • Register direct - Instruction is encoded with cogRAM address (register number). Data is in that register.
    • Register indirect - Instruction pair (ALTx prefix) is encoded with cogRAM pointer (address of address within cogRAM).
    • Memory direct - Load/store instruction (eg: RDLONG) is immediate encoded with hubRAM address. Data is at that hubRAM address. AUGmented above address #255.
    • Direct memory direct - Load/store instruction is encoded with cogRAM address (register number). Register points to data in hubRAM.
    • Indirect memory direct - Load/store instruction pair (ALTS prefix) is encoded with cogRAM pointer (address of address within cogRAM). Which points to hubRAM data.
  • evanhevanh Posts: 12,230
    edited 2022-01-16 00:07

    Hmm, there's also PTRA/B indexing. My brain's farting right now ... Indexed memory direct maybe.

    EDIT: Found my earlier suggestions - https://forums.parallax.com/discussion/comment/1524252/#Comment_1524252

  • pik33pik33 Posts: 1,226

    I feel like obscuring the nature of ALTx may be somewhat harmful. If it just looks like an addressing mode, you maybe wouldn't realize that using it repeatedly doubles the time and size the code requires and that it can be used in creative ways.

    I think nobody wants to remove original ALTx instruction form the asm so you can still use ALTx as you can still use setq/imm instead of ##

    About size and time... classic processors do the same: some instructions have prefixes, they have more bytes and execute longer, it is normal. We can treat altx+next instruction combination as single 64-bit opcode which executes in 4 clocks while still understanding the nature of these instructions.

Sign In or Register to comment.