I've started documenting the instruction set yet again but this time I am hopeful. Unlike last time I will use a Google document for each section of the manual, with the initial one being the instruction set. Since each document will be relatively small it should be fairly easy for a few collaborators to work on together. I'm not sure what format I will use but I started off with this: (link)
Anyone can view and comment but you need to sign in with an account and request edit access.
Agreed - nice work Peter.
However, I think the C & Z flags are different to the P1 for the rotates/shifts in that the C & Z flags will now be set with the result, not the source. So this needs to be checked.
Needed for code such as that below. Perhaps it is covered as the Destination and we should separate the register definition into source and destination ???
ANDN DIRA,#$03 'turn off P0 & P1
OR OUTA,#$0C ' P2=P3=1
Perhaps it would be an ideal time to just make the read return the register rather than the ram for both source and destination, or does this complicate things???
Another question: Might this be more correct ??? ...
Yeah, that looks better, that double latch representation stood out the first time I saw it too. I'd guess the way it ended up will be a side effect of how Chip was editing at the time and he's never gone back to review it.
Sounding pretty good. I was getting worried again that Chip hit a brick wall, but sounds like he's almost there...
Separate ROM sounds great to me. I vaguely remember some weirdness about ROM memory space overlapping with RAM space before.
Sounds like the RAM will be "clean" of ROM now...
Needed for code such as that below. Perhaps it is covered as the Destination and we should separate the register definition into source and destination ???
ANDN DIRA,#$03 'turn off P0 & P1
OR OUTA,#$0C ' P2=P3=1
Perhaps it would be an ideal time to just make the read return the register rather than the ram for both source and destination, or does this complicate things???
The RAM and the OUTA register hold the same value, because they are always both written, so it does not matter if you make a read-modify-write with the RAM as read-source or with the OUTA as read-source.
Mapping OUTA into the registers also for reads will need another 32bit Multiplexer and some address decoding. Why do that if you get it for free with the RAM-block?
The RAM and the OUTA register hold the same value, because they are always both written, so it does not matter if you make a read-modify-write with the RAM as read-source or with the OUTA as read-source.
Mapping OUTA into the registers also for reads will need another 32bit Multiplexer and some address decoding. Why do that if you get it for free with the RAM-block?
Andy
Thanks Andy. Of course you are correct. This comment should be added to avoid any confusion.
David, IIRC I think it's 19bits, because you can read from an unaligned address. although I could be wrong, I've been so busy lately I can't remember everything I've seen in these threads
David, IIRC I think it's 19bits, because you can read from an unaligned address. although I could be wrong, I've been so busy lately I can't remember everything I've seen in these threads
Ah, I guess I missed that. It seems like a waste of two bits though.
As opposed to wasting 32-bits for an extra instruction almost every time to shift it over? For a net gain of -30 bits?
Anyways glad to see things moving on again.
This is an immediate field. It would be the compiler or assembler that would shift the address not code at runtime. However, it could be that this instruction format with a 19 bit immediate field would be used for other instructions as well so maybe it helps to be consistent.
This is an immediate field. It would be the compiler or assembler that would shift the address not code at runtime. However, it could be that this instruction format with a 19 bit immediate field would be used for other instructions as well so maybe it helps to be consistent.
It could be used with a rdbyte (ie for tables etc) so best to have the whole 19 bits if possible. Otherwise we would be limited to longs in hub which would be wasteful in some circumstances.
It could be used with a rdbyte (ie for tables etc) so best to have the whole 19 bits if possible. Otherwise we would be limited to longs in hub which would be wasteful in some circumstances.
Yup, that is my understanding too, Chip wanted rdbyte to have a natural byte base.
Of course, the final address fed to the physical RAM is 32b index, and the lower 2 bits select the presented byte.
It gets more 'interesting' if two COGS write to adjacent bytes - IIRC RMW hw was talked about for that.
Not sure what Chip has finally done for this instance.
I could do with a little help on the instruction set as there are a lot of instructions I know nothing about although I have been googling this information to find out a little bit more. You wouldn't have to worry about formatting or diagrams but if you know something about an instruction or you would like to correct the wording then please open the shared document and click share to request edit permissions.
BTW, with edit permissions the document is no longer paginated and is much easier to work with but I've also changed the page size to A3 portrait so I still get the view width but also a longer page which makes it easier in the read-only format.
Remember, this is a work in progress and there are a lot of things that aren't correct but I'm just trying to get a feel for layout at least.
Peter, the last documents that Chip put out would have much of the information required for the additional instructions. The info was in a file included with the fpga code.
Peter, the last documents that Chip put out would have much of the information required for the additional instructions. The info was in a file included with the fpga code.
I was going to ask you for a link because there is a lot of stuff buried out there but I did look in your emulation sticky and found a zip with Prop2_Docs.txt but it looks awfully out of date and not applicable etc. All I'm really asking for at the moment is for anyone in the know to put their two cents worth into the documentation, preferably directly editing this. If for some reason things get messed up it doesn't matter too much as Google Docs keeps track of changes and allows me to revert to earlier versions, even several revisions per day. The important thing is the content, not the formatting as that can be applied and changed at any time.
I could start up a separate thread just for the documentation but I know that stuff will be posted here too. Anyway, I will plug away at it.
Peter,
I am looking at your google docs but not really sure how to edit it yet.
Here are a few things as I find them...
"L" is for immediate D value (equivalent to "I" for immediate S value). This is available on some instructions only.
SETCOND D,S/# sets the CCCC bits in D to the lower 4 bits in S (similar to old MOVI but sets the condition code CCCC bits of an instruction)
SETI D,S/# sets the IIIIIIICZ bits in D to the lower 9 bits in S (was MOVI)
SETS & SETD were MOVS & MOVD.
GETS & GETD get the S & D fields (9 bits). I presume they are placed into the lower 9 bits of D and the upper bits must be zeroed. Otherwise GETS doesn't make any sense???
SETDS sets both the S & D fields within the D register to the same lower 9 bits in S (confirm anyone??)
Might it simplify the logic if the "L" bit were only used in the "Z" position, instead of Z/C/I positions?
The only potential problem I can see is with the COGID instruction - do we need to check the Z flag on COGID???
Please also check the SETQ instruction - should this have an "L" option?
BTW should CALLB #abs and CALLB @rel have Z=1?
--LS 1100000 L0 I CCCC DDDDDDDDD SSSSSSSSS JP D/#,S/@ ; adr
--LS 1100000 L1 I CCCC DDDDDDDDD SSSSSSSSS JNP D/#,S/@ ; adr
--LS 1100001 L0 I CCCC DDDDDDDDD SSSSSSSSS REP D/#,S/# ;
--LS 1100010 L0 I CCCC DDDDDDDDD SSSSSSSSS WRFAST D/#,S/PTRx ; hub
--LS 1100010 L1 I CCCC DDDDDDDDD SSSSSSSSS WRBYTE D/#,S/PTRx ; hub
--LS 1100011 L0 I CCCC DDDDDDDDD SSSSSSSSS WRWORD D/#,S/PTRx ; hub
--LS 1100011 L1 I CCCC DDDDDDDDD SSSSSSSSS WRLONG D/#,S/PTRx ; hub
--LS 1100100 L0 I CCCC DDDDDDDDD SSSSSSSSS RDFAST D/#,S/PTRx ; hub
--LS 1101000 L0 I CCCC DDDDDDDDD SSSSSSSSS QSINCOS D/#,S/# ; 2
--LS 1101000 L1 I CCCC DDDDDDDDD SSSSSSSSS QARCTAN D/#,S/# ; 2
--LS 1101001 L0 I CCCC DDDDDDDDD SSSSSSSSS QROTATE D/#,S/# ; 3
--LS 1101001 L1 I CCCC DDDDDDDDD SSSSSSSSS QMUL D/#,S/# ; 2
--LS 1101010 L0 I CCCC DDDDDDDDD SSSSSSSSS QDIV D/#,S/# ; 3
--LS 1101010 L1 I CCCC DDDDDDDDD SSSSSSSSS QSQRT D/#,S/# ; 2
-CLS 1101011 L0 I CCCC DDDDDDDDD SSSSSSSSS COGINIT D/#,S/# ;wr if !L 2
-CLS 1101011 L1 I CCCC DDDDDDDDD SSSSSSSSS COGINIT D/#,S/# WC ;wr if !L 2
ZCL- 1101111 0C L CCCC DDDDDDDDD 000000000 CLKSET D/# ;wr if C 1
ZCL- 1101111 ZC L CCCC DDDDDDDDD 000000001 COGID D/# WC ;wr if !WC 0/1
ZCL- 1101111 00 L CCCC DDDDDDDDD 000000011 COGSTOP D/# ; 1
ZCL- 1101111 00 L CCCC DDDDDDDDD 000000101 LOCKRET D/# ; 1
ZCL- 1101111 0C L CCCC DDDDDDDDD 000000110 LOCKCLR D/# ; 1
ZCL- 1101111 0C L CCCC DDDDDDDDD 000000111 LOCKSET D/# ; 1
ZCL- 1101111 00 L CCCC DDDDDDDDD 000001110 QLOG D/# ; 1
ZCL- 1101111 00 L CCCC DDDDDDDDD 000001111 QEXP D/# ; 1
ZCL- 1101111 00 L CCCC DDDDDDDDD 000010000 SETQ D/# ;
ZCL- 1101111 00 L CCCC DDDDDDDDD 000011000 WFWORD D/# ;
ZCL- 1101111 00 L CCCC DDDDDDDDD 000011100 WFLONG D/# ;
--LS 1100000 0L I CCCC DDDDDDDDD SSSSSSSSS WAITPAN D/#,S/# ; *
--LS 1100000 1L I CCCC DDDDDDDDD SSSSSSSSS WAITPAE D/#,S/# ; *
--LS 1100001 0L I CCCC DDDDDDDDD SSSSSSSSS WAITPBN D/#,S/# ; *
--LS 1100001 1L I CCCC DDDDDDDDD SSSSSSSSS WAITPBE D/#,S/# ; *
--LS 1100100 0L I CCCC DDDDDDDDD SSSSSSSSS MSGOUTA D/#,S/# ; *
--LS 1100100 1L I CCCC DDDDDDDDD SSSSSSSSS MSGOUTB D/#,S/# ; *
--LS 1100110 0L I CCCC DDDDDDDDD SSSSSSSSS PICKZC D/#,S/# ; * adr
--L- 1101111 00 L CCCC DDDDDDDDD xxxxx0110 PUSH D/# ; *
--L- 1101111 00 L CCCC DDDDDDDDD xxxxx0111 SETVID D/# ; *
--L- 1101111 00 L CCCC DDDDDDDDD xxxxx1000 WAIT D/# ; *
--L- 1101111 00 L CCCC DDDDDDDDD xxxxx1001 WAITPX D/# ; *
--L- 1101111 00 L CCCC DDDDDDDDD xxxxx1010 WAITPR D/# ; *
--L- 1101111 00 L CCCC DDDDDDDDD xxxxx1011 WAITPF D/# ; *
---- 1101111 00 x CCCC xxxxxxxxx xxxxx1100 SETQ D/# ; *
Comments
Anyone can view and comment but you need to sign in with an account and request edit access.
However, I think the C & Z flags are different to the P1 for the rotates/shifts in that the C & Z flags will now be set with the result, not the source. So this needs to be checked.
Should the following registers be read too to cater for read-modify-write ???
Needed for code such as that below. Perhaps it is covered as the Destination and we should separate the register definition into source and destination ???
ANDN DIRA,#$03 'turn off P0 & P1
OR OUTA,#$0C ' P2=P3=1
Perhaps it would be an ideal time to just make the read return the register rather than the ram for both source and destination, or does this complicate things???
The trick of using registers $1F2-1F9 (includes PTRA & PTRB) for LOCADDR & LINK instructions is a nice addition.
Note: If there are more, I will just add here...
Yeah, that looks better, that double latch representation stood out the first time I saw it too. I'd guess the way it ended up will be a side effect of how Chip was editing at the time and he's never gone back to review it.
Thanks Chip!
Separate ROM sounds great to me. I vaguely remember some weirdness about ROM memory space overlapping with RAM space before.
Sounds like the RAM will be "clean" of ROM now...
The RAM and the OUTA register hold the same value, because they are always both written, so it does not matter if you make a read-modify-write with the RAM as read-source or with the OUTA as read-source.
Mapping OUTA into the registers also for reads will need another 32bit Multiplexer and some address decoding. Why do that if you get it for free with the RAM-block?
Andy
As opposed to wasting 32-bits for an extra instruction almost every time to shift it over? For a net gain of -30 bits?
Anyways glad to see things moving on again.
Yup, that is my understanding too, Chip wanted rdbyte to have a natural byte base.
Of course, the final address fed to the physical RAM is 32b index, and the lower 2 bits select the presented byte.
It gets more 'interesting' if two COGS write to adjacent bytes - IIRC RMW hw was talked about for that.
Not sure what Chip has finally done for this instance.
BTW, with edit permissions the document is no longer paginated and is much easier to work with but I've also changed the page size to A3 portrait so I still get the view width but also a longer page which makes it easier in the read-only format.
Remember, this is a work in progress and there are a lot of things that aren't correct but I'm just trying to get a feel for layout at least.
Shared instruction set document (comment only)
Public read only webpage document
This could be on the forums, preferably, as it might guide more people into helping, but alternatively could be in-document
I was going to ask you for a link because there is a lot of stuff buried out there but I did look in your emulation sticky and found a zip with Prop2_Docs.txt but it looks awfully out of date and not applicable etc. All I'm really asking for at the moment is for anyone in the know to put their two cents worth into the documentation, preferably directly editing this. If for some reason things get messed up it doesn't matter too much as Google Docs keeps track of changes and allows me to revert to earlier versions, even several revisions per day. The important thing is the content, not the formatting as that can be applied and changed at any time.
I could start up a separate thread just for the documentation but I know that stuff will be posted here too. Anyway, I will plug away at it.
I am looking at your google docs but not really sure how to edit it yet.
Here are a few things as I find them...
"L" is for immediate D value (equivalent to "I" for immediate S value). This is available on some instructions only.
SETCOND D,S/# sets the CCCC bits in D to the lower 4 bits in S (similar to old MOVI but sets the condition code CCCC bits of an instruction)
SETI D,S/# sets the IIIIIIICZ bits in D to the lower 9 bits in S (was MOVI)
SETS & SETD were MOVS & MOVD.
GETS & GETD get the S & D fields (9 bits). I presume they are placed into the lower 9 bits of D and the upper bits must be zeroed. Otherwise GETS doesn't make any sense???
SETDS sets both the S & D fields within the D register to the same lower 9 bits in S (confirm anyone??)
I have been looking at your new instruction set.
Might it simplify the logic if the "L" bit were only used in the "Z" position, instead of Z/C/I positions?
The only potential problem I can see is with the COGID instruction - do we need to check the Z flag on COGID???
Please also check the SETQ instruction - should this have an "L" option?
BTW should CALLB #abs and CALLB @rel have Z=1?
--LS 1100000 L0 I CCCC DDDDDDDDD SSSSSSSSS JP D/#,S/@ ; adr --LS 1100000 L1 I CCCC DDDDDDDDD SSSSSSSSS JNP D/#,S/@ ; adr --LS 1100001 L0 I CCCC DDDDDDDDD SSSSSSSSS REP D/#,S/# ; --LS 1100010 L0 I CCCC DDDDDDDDD SSSSSSSSS WRFAST D/#,S/PTRx ; hub --LS 1100010 L1 I CCCC DDDDDDDDD SSSSSSSSS WRBYTE D/#,S/PTRx ; hub --LS 1100011 L0 I CCCC DDDDDDDDD SSSSSSSSS WRWORD D/#,S/PTRx ; hub --LS 1100011 L1 I CCCC DDDDDDDDD SSSSSSSSS WRLONG D/#,S/PTRx ; hub --LS 1100100 L0 I CCCC DDDDDDDDD SSSSSSSSS RDFAST D/#,S/PTRx ; hub --LS 1101000 L0 I CCCC DDDDDDDDD SSSSSSSSS QSINCOS D/#,S/# ; 2 --LS 1101000 L1 I CCCC DDDDDDDDD SSSSSSSSS QARCTAN D/#,S/# ; 2 --LS 1101001 L0 I CCCC DDDDDDDDD SSSSSSSSS QROTATE D/#,S/# ; 3 --LS 1101001 L1 I CCCC DDDDDDDDD SSSSSSSSS QMUL D/#,S/# ; 2 --LS 1101010 L0 I CCCC DDDDDDDDD SSSSSSSSS QDIV D/#,S/# ; 3 --LS 1101010 L1 I CCCC DDDDDDDDD SSSSSSSSS QSQRT D/#,S/# ; 2 -CLS 1101011 L0 I CCCC DDDDDDDDD SSSSSSSSS COGINIT D/#,S/# ;wr if !L 2 -CLS 1101011 L1 I CCCC DDDDDDDDD SSSSSSSSS COGINIT D/#,S/# WC ;wr if !L 2 ZCL- 1101111 0C L CCCC DDDDDDDDD 000000000 CLKSET D/# ;wr if C 1 ZCL- 1101111 ZC L CCCC DDDDDDDDD 000000001 COGID D/# WC ;wr if !WC 0/1 ZCL- 1101111 00 L CCCC DDDDDDDDD 000000011 COGSTOP D/# ; 1 ZCL- 1101111 00 L CCCC DDDDDDDDD 000000101 LOCKRET D/# ; 1 ZCL- 1101111 0C L CCCC DDDDDDDDD 000000110 LOCKCLR D/# ; 1 ZCL- 1101111 0C L CCCC DDDDDDDDD 000000111 LOCKSET D/# ; 1 ZCL- 1101111 00 L CCCC DDDDDDDDD 000001110 QLOG D/# ; 1 ZCL- 1101111 00 L CCCC DDDDDDDDD 000001111 QEXP D/# ; 1 ZCL- 1101111 00 L CCCC DDDDDDDDD 000010000 SETQ D/# ; ZCL- 1101111 00 L CCCC DDDDDDDDD 000011000 WFWORD D/# ; ZCL- 1101111 00 L CCCC DDDDDDDDD 000011100 WFLONG D/# ; --LS 1100000 0L I CCCC DDDDDDDDD SSSSSSSSS WAITPAN D/#,S/# ; * --LS 1100000 1L I CCCC DDDDDDDDD SSSSSSSSS WAITPAE D/#,S/# ; * --LS 1100001 0L I CCCC DDDDDDDDD SSSSSSSSS WAITPBN D/#,S/# ; * --LS 1100001 1L I CCCC DDDDDDDDD SSSSSSSSS WAITPBE D/#,S/# ; * --LS 1100100 0L I CCCC DDDDDDDDD SSSSSSSSS MSGOUTA D/#,S/# ; * --LS 1100100 1L I CCCC DDDDDDDDD SSSSSSSSS MSGOUTB D/#,S/# ; * --LS 1100110 0L I CCCC DDDDDDDDD SSSSSSSSS PICKZC D/#,S/# ; * adr --L- 1101111 00 L CCCC DDDDDDDDD xxxxx0110 PUSH D/# ; * --L- 1101111 00 L CCCC DDDDDDDDD xxxxx0111 SETVID D/# ; * --L- 1101111 00 L CCCC DDDDDDDDD xxxxx1000 WAIT D/# ; * --L- 1101111 00 L CCCC DDDDDDDDD xxxxx1001 WAITPX D/# ; * --L- 1101111 00 L CCCC DDDDDDDDD xxxxx1010 WAITPR D/# ; * --L- 1101111 00 L CCCC DDDDDDDDD xxxxx1011 WAITPF D/# ; * ---- 1101111 00 x CCCC xxxxxxxxx xxxxx1100 SETQ D/# ; *Sounds like you made leaps and bounds of progress!
I will start digesting the latest instruction set while wifey naps (we just got back from an Alaska cruise).
"I compiled all 16 cogs and it took ~83k LE's, or 72% of the DE2-115's FPGA."
Sounds like four cogs should fit in a DE0-Nano.
Cluso+Peter Jakacki:
Nice work on more docs.
pjv will not take credit for docs... I suspect that belongs to Peter Jakacki.
Cheers,
Peter (pjv)