Suggested change to LINK & LOCADDR instructions
ozpropdev
Posts: 2,792
Hi Chip/All
Looking at the latest instruction set may I make the following suggestion.
If regs 1F2 to 1F7 are named PTR0 to PTR5
So LOCADDR becomes LOCADR0 .. LOCADR5,LOCADRA and LOCADRB
and LINK becomes LINK0 .. LINK5,LINKA and LINKB
As PTRA/B have special additional indexing abilities the LINKA and LINKB names would help to remind users of
of their potential overlap. Less likely to accidently overwrite PTRA/B values.
While on the subject of PNUT stuff, in the last version we had the Ctrl-G "Get Hardware Version" facility.
Can this be enhanced to include the FPGA build version/release too.
Same for PNUT's "Info" screen to reflect it's version. Based on the history of "ye olde P2" testing it was
sometimes necessary to switch between versions to verify/debug verilog changes.
Thoughts?
Cheers
Brian
Looking at the latest instruction set may I make the following suggestion.
If regs 1F2 to 1F7 are named PTR0 to PTR5
1F2 PTR0 1F3 PTR1 1F4 PTR2 1F5 PTR3 1F6 PTR4 1F7 PTR5 1F8 PTRA 1F9 PTRB 1FA INA 1FB INB 1FC OUTA 1FD OUTB 1FE DIRA 1FF DIRBAnd the names of the following instructions be changed from
---- wr * 111000r rrn CCCC nnnnnnnnn nnnnnnnnn LOCADDR reg,#abs adr (write 19-bit absolute address to $1F2..$1F9, includes PTRA/PTRB)
---- wr * 111001r rrn CCCC nnnnnnnnn nnnnnnnnn LOCADDR reg,@rel adr (write 19-bit relative address to $1F2..$1F9, includes PTRA/PTRB)
---- wr * 111010r rrn CCCC nnnnnnnnn nnnnnnnnn * LINK reg,#abs adr (jump to 19-bit absolute address, write {Z,C,P[18:0]} to $1F2..$1F9)
---- wr * 111011r rrn CCCC nnnnnnnnn nnnnnnnnn * LINK reg,@rel adr (jump to 19-bit relative address, write {Z,C,P[18:0]} to $1F2..$1F9)
to
---- wr * 111000r rrn CCCC nnnnnnnnn nnnnnnnnn LOCADRx #abs ---- wr * 111001r rrn CCCC nnnnnnnnn nnnnnnnnn LOCADRx @rel ---- wr * 111010r rrn CCCC nnnnnnnnn nnnnnnnnn * LINKx #abs ---- wr * 111011r rrn CCCC nnnnnnnnn nnnnnnnnn * LINKx @rel
So LOCADDR becomes LOCADR0 .. LOCADR5,LOCADRA and LOCADRB
and LINK becomes LINK0 .. LINK5,LINKA and LINKB
As PTRA/B have special additional indexing abilities the LINKA and LINKB names would help to remind users of
of their potential overlap. Less likely to accidently overwrite PTRA/B values.
While on the subject of PNUT stuff, in the last version we had the Ctrl-G "Get Hardware Version" facility.
Can this be enhanced to include the FPGA build version/release too.
Same for PNUT's "Info" screen to reflect it's version. Based on the history of "ye olde P2" testing it was
sometimes necessary to switch between versions to verify/debug verilog changes.
Thoughts?
Cheers
Brian
Comments
LOCADDR ptr, #/@
LINK ptr,#/@
as that only needs two pasm assembly instructions
BUT
I like ptr = {PTR0, PTR1, PTR2, PTR3, PTR4, PTR5, PTRA, PTRB}
However, I wonder if it might be prudent to start at $1F3 so we get this... This would mean that effectively the last PTR would use INDA which effectively means a JUMP rather than a LINK because a write to INA is ignored.
So we could do
LINK NUL,#/@
which is effectively...
JMP #/@
This could save an instruction opcode(s) and perhaps simplify the logic ???
Perhaps there could be further logic simplification by re-examining all JMP/CALL/RET instructions again ???
BTW Maybe we should name (predefine in the assembler) all the 1F0-1F7 registers as PTR0-PTR7 and the LOCADR and LINK instructions would use PTR3-PTR7, PTRA, PTRB, NUL.
I wonder if they should/could be mapped into the 1F0/1F1 registers ???
Could there be a benefit where we could then manipulate those values directly with normal instructions such as ADD/SUB/XOR... ???
Just a thought.
The idea behind LINKx and LOCADRx was to keep consistency with existing instruction formats.
Using the following instructions as an example.
@Ray
Your mapping idea works too.
But just giving the registers some official names would be fine.
Cheers
Brian
Ray
What are the ACCA/ACCB that you are referring to?
I see no reference to these in the latest instruction set.
Cheers
Brian
I'd leave the registers alone, because it might be handy to have six easily loadable pointers - however good point about JMP, because we could just agree on using
LINK PTR5,#/@
as JMP, igonoring PTR5 after that if we want. This would still allow saving an op code
However I think it is best if we leave Chip alone at least until we get PNut/FPGA images.
- For tight pasm code, the four level LIFO stack is great, so we should keep it
- for hubexec compiled code, the PTRA/PTRB call/ret is fantastic, so we need those
Perhaps it would be feasible to only keep PTRA call/ret, however there is a certain symmetry in keeping both A/B variants.