Instructions that inject results into the next instruction

Seairth · 2019-02-12 00:41

It occurs to me that SCA, SCAS, GETXACC, and XORO32 have an issue from a discovery perspective. All four instructions stuff a value into the next instructions S register, but the subsequent instruction doesn't look any different. In other words, it is not immediately obvious that "something else" is going on. I am not suggesting that the instructions should be changed, mind you. Instead, I'm thinking that there should be some means to easily indicate this in the code. But a particular recommendation escapes me. I know the old "0-0" trick for P1 might work, but it doesn't feel like a real solution. So, for now, I'm just putting it out there for discussion.

evanh · 2019-02-12 01:03

In addition, if things ever move on to data being inserted to D port instead of S port then a simple textual placeholder won't even show up any longer because the D field still has valid use specifying the result register/address. The magic won't even be hinted at any longer.

evanh · 2019-02-12 01:25

It's not just those four either. The multitude of ALTx instructions fall under this as well.

Seairth · 2019-02-12 01:44

evanh wrote: »

It's not just those four either. The multitude of ALTx instructions fall under this as well.

True, but I left them out because they at least "ALT" something.

Cluso99 · 2019-02-12 12:12

And the AUG instructions which add insert the top 23 bits. Often used as a byproduct of XXXX D,##S

Mark_T · 2019-02-12 12:23

But ## syntax does look different, and the AUGS/AUGD instructions never need appear anyhow.
I guess it would be nice to hide ALTS/D/R with similar syntactic sugar too.

    ALTS    index,#table    ‘set next S field to table+index
    MOV     OUTA,0        ‘output register[table+index] to OUTA
coded by
    MOV    OUTA, table[index]


    ALTR    index,#table    ‘set next write to table+index
    XOR     INA,INB        ‘write INA^INB to register[table+index]
coded by
    XOR    table[index], INA, INB


    ALTS    pointer        ‘set next S field to pointer
    MOV     OUTA,0        ‘output register[pointer] to OUTA
coded by
    MOV    OUTA, [pointer]

Seairth · 2019-02-12 12:27

Cluso99 wrote: »

And the AUG instructions which add insert the top 23 bits. Often used as a byproduct of XXXX D,##S

Except, in those cases, you still use all operands in the next instruction. The ALT instructions also do exactly what they say, though you still end up having to place a dummy/placeholder in the appropriate operand of the next instruction.

msrobots · 2019-02-12 17:16

I think hiding the alt instructions is a bad idea, since one often needs to count instructions. to get the size in longs. To remember that xx nedas one more the x is easy to remember, but more cases get cumbersome.

Enjoy!

M ike

iseries · 2019-02-12 19:12

I think the hole instruction set is a nightmare. What a kludge.

I can't image how a programming language could be developed to use it. I guess we will be stuck with assembler.

Mike

Seairth · 2019-02-12 19:59

iseries wrote: »

I think the hole instruction set is a nightmare. What a kludge.

I can't image how a programming language could be developed to use it. I guess we will be stuck with assembler.

That's not really germane to this discussion, I think.

potatohead · 2019-02-12 20:41

LMAO!

Iseries, just you watch.

potatohead · 2019-02-12 20:45

Re: hidden actions

I happen to be flipping through my Moto 6809 programmers reference.

This book is beautiful. Each instruction has a page, and what you need to know is on that page. It is super easy to use.

Seems to me we can do a similar thing here. Page for each instruction, code snippet, effects.

As of right now, the syntax is lean and mean. Would hate to see it cluttered further over what is largely a documentation problem..

iseries · 2019-02-12 20:46

Sorrry, I thought we were talking about altered states or maybe Augmentation surgery.

Mike

msrobots · 2019-02-12 20:56

actually the PASM2 language is no nightmare at all, at least when you know p1 PASM a bit.

and with fastspin yuou have Spin1/2, Basic and C already as HLLs available. There is also Prop2gcc(?) using the existing port of gcc for the P1 and reworks the generated P1 PASM into P2 PASM.

The actual port from gcc for p2 is planned and some work is already done for P2 hot some intermediate P2.

Enjoy!

Mike

Mark_T · 2019-02-12 21:02

iseries wrote: »

I think the hole instruction set is a nightmare. What a kludge.

I can't image how a programming language could be developed to use it. I guess we will be stuck with assembler.

Mike

Have you written compiler backends and code generators? Take it from someone who has that the instruction
set is a lot better than many - lots of registers that are completely orthogonal is a huge benefit, all these AUG and
ALT instructions are just addressing modes in disguise, plenty of basic ALU operations. Compiling for the cordic
pipeline is no more tricky than for any other pipelined processor, and it can be used naively easily with lower
performance, and the block memory reads and writes enable efficient stack use.

iseries · 2019-02-12 21:46

I like the P1 instruction set. Clean and to the point. No Alter, Aug, or strange address areas. Read from this location and write to that location.

This should be more like RISC instructions or ARM based. Less is more these days.

Mike

jmg · 2019-02-12 23:37

Seairth wrote: »

It occurs to me that SCA, SCAS, GETXACC, and XORO32 have an issue from a discovery perspective. All four instructions stuff a value into the next instructions S register, but the subsequent instruction doesn't look any different. In other words, it is not immediately obvious that "something else" is going on. I am not suggesting that the instructions should be changed, mind you. Instead, I'm thinking that there should be some means to easily indicate this in the code. But a particular recommendation escapes me. I know the old "0-0" trick for P1 might work, but it doesn't feel like a real solution. So, for now, I'm just putting it out there for discussion.

Valid point.
It has been suggested before that these unclear-patches of two lines, be presented to the user as a single, 3 operand opcodes, where that is clearer.
They really are 64 bit opcodes, and the user should not be bothered by needing to know the two obtuse jig-saw pieces that make up the 64b opcode..
Other MCUs have variable length opcodes, and anyone wanting to know exact sizes, and even exact break-downs, can always look at generated list files.

Mark_T · 2019-02-12 23:43

You could also use a marker (like wz, wc, perhaps 'ex' for extended) after the instuction to say you are allowing the
instruction to be more than one long. A warning would be generated for any multi-long instruction not annotated this way?

[ actually rather than 'ex', perhaps ##, since this already serves the purpose for AUGS/AUGD, or 'aug' ]

rogloh · 2019-02-13 00:55

We used to see both 0-0 and #0-0 variants used on P1 to indicate a patched instruction argument for both D and/or S, so perhaps the same thing still works ok for P2 in many cases. For those that don't it can potentially be further extended to 00-00 or #00-00 forms to indicate this instruction's write address gets affected by some special prior instruction such as ALTR/ALTI etc.

Also if we still need to keep some original argument name lying around for D instead of using 00-00 maybe we can just put in "d_value-00" for the D field assuming the assembler allows it and won't affect the generated code in any way. I agree it is not perfect but at least helps show something special happens there that is different from the 0-0 case.

' Example: sample input data from INA port and compare with a sample
' varying mask table in COG RAM and write result values to result table (100 longs).
' In this case alticonst would be setup for INC D, and patch and INC R.


SETR  output_pos, #result_table ' initialize table result output position
REP   #2, #100 ' sample 100 times
ALTI  output_pos, alticonst   ' alter next instruction according to alticonst 
XOR   mask_table-00, INA   ' the "-00" form indicates result gets patched here, and result is not written to mask_table

Phil Pilgrim (PhiPi) · 2019-02-13 01:49

$-$

-Phil

evanh · 2019-02-13 03:08

Mark_T wrote: »

You could also use a marker (like wz, wc, perhaps 'ex' for extended) after the instuction to say you are allowing the
instruction to be more than one long. A warning would be generated for any multi-long instruction not annotated this way?

This has future-proofing for Prop3, as the port injection will be an optional parameter there. Although it doesn't resolve the immediate concern over erratic looking sources.

msrobots · 2019-02-13 04:00

I think I changed my mind about this, thinking about my setbyte x,y #n problem where I needed setbyte x,y,n and had a hard ttime ti figure it out.

So maybe not a bad idea to add aliases to the existing instruction pairs.

Enjoy!

Mike

Electrodude · 2019-02-13 04:47

Phil Pilgrim (PhiPi) wrote: »

$-$

-Phil

How about an explicit placeholder symbol, such as $$, which lets the compiler know that you know what you're doing and lets it produce a warning when you don't use it?

evanh · 2019-02-13 04:48

msrobots wrote: »

So maybe not a bad idea to add aliases to the existing instruction pairs.

But part of that problem was the alias generated incorrect machine code. :P

msrobots · 2019-02-13 06:51

yes and no, the compiler did produced incorrect code, but that has @ersmith fixed. But I still need to write two long instructions to archive getbyte a,a,n and setbyte a, c, n with n in a register not in a constant.
setxxxx/getxxxx are all 3 op instructions, just the last op is a constant thus from the PASM syntax would if fit right in, just a macro in assembler...

Enjoy!

Mike

Instructions that inject results into the next instruction

Comments