Bill, I would bet that Chip would put more effort into a self-hosting Prop dev environment than getting an ARM core up and running, that's an exercise left to others. A self-hosted environment would still work on the regular chips.
P2 chips can provide this environment IMHO. Once we have production P2 chips, they will be enough to bootstrap future propellers into running. Tons of reasons to do this. Eating the dog food to make better dog food is a significant gain, and point of sale. The gain is the control over the whole stack of technology. This is significant. The point of sale is the value added though this control, think Apple instead of Dell for example, and the fact that the technology can stand on it's own speaks to it's robustness, etc...
Open tools can be built for whatever CPU you want. And people will too. But the core development can build up on P2 chips, and remain controlled and consistent throughout P3 development. No OS or hardware worries of any kind.
That is if Parallax makes the P3 dev board. That one can have a P2 on it. Would be useful for other things too.
Hi Chip, I can program the DE2, and it verifies, and I can talk to the P2 with PNut, but it's not running, or I'm getting no sync, could be something to do with the expansion board?
Hi Chip, I can program the DE2, and it verifies, and I can talk to the P2 with PNut, but it's not running, or I'm getting no sync, could be something to do with the expansion board?
When you do a Ctrl-G from PNut, does it recognize the DE2-115 w/5 cogs and 128KB hub RAM? And do you have the 2.5" x 2.75" blue HSMC adapter board from Parallax that is marked "Terasis_DE2_115"? You would connect your VGA cable to the Parallax adapter board, not the one built into the DE2-115 base board.
Chip,
SETX - what bits are moved?
INCPAT/DECPAT - what do these do?
All,
Been working thru the instruction changes required to my P2 Debugger.
Here are a few changes...
movi/movd/movs -> seti/setd/sets - and there is a new setx instruction.
I use SHR #n WZ,WC,NR in a number of places
Now to look at the test style instructions
I knew there would be a few gotchas with the NR but we are way better of with the new set of instructions!
Chip,
SETX - what bits are moved?
INCPAT/DECPAT - what do these do?
All,
Been working thru the instruction changes required to my P2 Debugger.
Here are a few changes...
movi/movd/movs -> seti/setd/sets - and there is a new setx instruction.
I use SHR #n WZ,WC,NR in a number of places
Now to look at the test style instructions
I knew there would be a few gotchas with the NR but we are way better of with the new set of instructions!
SETX is for the five D bits between SETD and SETI.
INCPAT goes to the next-higher bit pattern with the same number of '1' bits (%10110 becomes %11001, then %11010, then %11100). DECPAT goes to the next-lower (reverse direction).
If you look at the items in the menu bar across the top of the applications, they're all in there.
Ctl-D (documentation toggle) but appears to do the same as Ctl-M. Perhaps its because I have an error (NR).
I had missed Ctl-G in the Run menu. My board is not connected.
SETX is for the five D bits between SETD and SETI.
Chip,
Now that the SETF,MOVF instructions have been removed, we no longer have incremental indexing of bytes in within a LONG.
Have you considered a SETN instruction to modify the n-value in the following instructions.
-MS 10010nn n0 I CCCC DDDDDDDDD SSSSSSSSS GETNIB D,S/#,#0..7
--MS 10010nn n1 I CCCC DDDDDDDDD SSSSSSSSS SETNIB D,S/#,#0..7
--MS 1001100 n0 I CCCC DDDDDDDDD SSSSSSSSS GETWORD D,S/#,#0..1
--MS 1001100 n1 I CCCC DDDDDDDDD SSSSSSSSS SETWORD D,S/#,#0..1
--MS 101000n n0 I CCCC DDDDDDDDD SSSSSSSSS GETBYTE D,S/#,#0..3
--MS 101000n n1 I CCCC DDDDDDDDD SSSSSSSSS SETBYTE D,S/#,#0..3
In a previous post I mentioned an issue when using INDx++ in a WAITVID instruction while multi-tasking.
This was solved byte using a SETINDx ++1 after the WAITVID instruction.
The new FPGA code seems to be having trouble with this arrangement and the effect is no or bad video signal.
I am now using SETD instructions to modify the WAITVID instruction.
Here are the changes I had to do to get my P2 Debugger code to compile.
This part was quite simple, but I had decided to use P1 instructions where possible.
Now I need to change the instruction decode tables etc.
Note "wait" is now a pnut reserved word and cannot be used for a pasm dat label.
With all of these changes I'm beginning to wonder if this new processor should be called something other than "Propeller".
Do you mean other than P2 ? as in P2.5 ?
Over at Microchip, they call anything with legs a 'PIC', which lets them boast about sales volumes etc, when really they have many different uC cores, swept under that one umbrella. ARM are a bit the same.
You will note that only the instructions GETWORD/SETWORD, WAITPEQ and WAITPNE have opcodes that have "1" bits in the 6th nibble (other than "n" bits). If these instruction opcodes were swapped with TESTB, WRBYTE/WRWORD and SQRT64/QSINCOS so that they had a "0" bits in those bits, then SETNIB D,[#]S,#6 could be used to set the "n/nn/nnn" bits (on a proviso the user had the nibble msb unused bits set as zeros).
This way we would not require a SETN instruction.
Chip,
Now that the SETF,MOVF instructions have been removed, we no longer have incremental indexing of bytes in within a LONG.
Have you considered a SETN instruction to modify the n-value in the following instructions.
-MS 10010nn n0 I CCCC DDDDDDDDD SSSSSSSSS GETNIB D,S/#,#0..7
--MS 10010nn n1 I CCCC DDDDDDDDD SSSSSSSSS SETNIB D,S/#,#0..7
--MS 1001100 n0 I CCCC DDDDDDDDD SSSSSSSSS GETWORD D,S/#,#0..1
--MS 1001100 n1 I CCCC DDDDDDDDD SSSSSSSSS SETWORD D,S/#,#0..1
--MS 101000n n0 I CCCC DDDDDDDDD SSSSSSSSS GETBYTE D,S/#,#0..3
--MS 101000n n1 I CCCC DDDDDDDDD SSSSSSSSS SETBYTE D,S/#,#0..3
In a previous post I mentioned an issue when using INDx++ in a WAITVID instruction while multi-tasking.
This was solved byte using a SETINDx ++1 after the WAITVID instruction.
The new FPGA code seems to be having trouble with this arrangement and the effect is no or bad video signal.
I am now using SETD instructions to modify the WAITVID instruction.
You'll see that for GETNIB/SETNIB/GETBYTE/SETBYTE, there are leading 0's on nibble #6 of the encoding. The idea is that you can do a 'SETNIB inst,value,#6' to make self-modifying code.
For GETWORD/SETWORD, there is only one 'n' bit that needs modifying and something like 'SETBC inst,#24' can handle the modification.
About WAITVID, note that its immediate D value can range from 0..$DFF because of special WAITVID instruction encoding.
Do these statements address the issues you were having?
You will note that only the instructions GETWORD/SETWORD, WAITPEQ and WAITPNE have opcodes that have "1" bits in the 6th nibble (other than "n" bits). If these instruction opcodes were swapped with TESTB, WRBYTE/WRWORD and SQRT64/QSINCOS so that they had a "0" bits in those bits, then SETNIB D,[#]S,#6 could be used to set the "n/nn/nnn" bits (on a proviso the user had the nibble msb unused bits set as zeros).
This way we would not require a SETN instruction.
How would it not require a SETN instruction? Are you saying we could get rid of it, somehow?
Because all the instructions with the "n/nn/nnn" encoding would now become "000n/00nn/0nnn" so that SETNIB would be able to set these bits in the same manner as SETNIB can now set COGINIT etc.
Because all the instructions with the "n/nn/nnn" encoding would now become "000n/00nn/0nnn" so that SETNIB would be able to set these bits in the same manner as SETNIB can now set COGINIT etc.
Okay, I understand. I'll look at your recommendation to see how it would fit.
In the previous FPGA version I used the following code
WAITVID INDB,MYCOLOR
SETINDB ++1
In the new FPGA this does not work,no or bad video signal.
If I remove the SETINDB instruction the video works again,but obviously without indexing is incorrect.
I'm still doing some testing on this.
I'm also chasing a issue with the replacement of POPAR,POPBR
POPBR S1
POPBR S2
POPB s3
This reads 2 longs then indexes back 1 step. This doesn't seem to work on the new FPGA.
PNut seems to accept these KEYWORDS without error.
I know RDAUX replaces some of these instructions, but I still haven't got a replacement to work yet.
I keep going and see what I find.
In the previous FPGA version I used the following code
WAITVID INDB,MYCOLOR
SETINDB ++1
In the new FPGA this does not work,no or bad video signal.
If I remove the SETINDB instruction the video works again,but obviously without indexing is incorrect.
I'm still doing some testing on this.
I'm also chasing a issue with the replacement of POPAR,POPBR
POPBR S1
POPBR S2
POPB s3
This reads 2 longs then indexes back 1 step. This doesn't seem to work on the new FPGA.
PNut seems to accept these KEYWORDS without error.
I know RDAUX replaces some of these instructions, but I still haven't got a replacement to work yet.
I keep going and see what I find.
Great work on the update.
Cheers
Brian
I'll look into the INDx issue in the morning. The encoding has changed, but if you are using PNut, it should take care of that for you.
About POPBR: it is different than before. It used to be that the 'R' indicated reverse pointer movement (SPx++ vs --SPx). Now, all POPs are --SPx and all PUSHes are SPx++, regardless of the 'R'. The 'R' now means that instead of the address, it will use !address, or 255-address. The 'R' makes reverse addressing. If you read the AUX section of the Prop2_Docs.txt, it will explain everything about this.
For PASM code loaded with F11 use ORGH $E00 instead of ORGH $E80
ROM Monitor entry address has changed
' Usage: cognew($6E4, rx_pin << 9 + tx_pin) 'start monitor in new cog
I found the $E00 change. Hadn't worked out the monitor address yet, so thanks.
The new DE0-Nano FPGA code is running but my P2 Debugger is not working yet - it compiles ok. I will try just booting into the monitor straight away and see if that helps.
When you do a Ctrl-G from PNut, does it recognize the DE2-115 w/5 cogs and 128KB hub RAM? And do you have the 2.5" x 2.75" blue HSMC adapter board from Parallax that is marked "Terasis_DE2_115"? You would connect your VGA cable to the Parallax adapter board, not the one built into the DE2-115 base board.
Yes, it recognises the DE2-115 w/5 cogs and 128KB hub RAM I also have the HSMC adapter board marked Terasic_DE2_115, and the VGA cable is plugged into that, and not the DE2 itself
I'll try it again later tonight, as I'm out to do a talk about making games to a load of 6th form art students.
@potatohead, yeah, I meant to try going back, but never got chance, will do it tonight!
Comments
Open tools can be built for whatever CPU you want. And people will too. But the core development can build up on P2 chips, and remain controlled and consistent throughout P3 development. No OS or hardware worries of any kind.
That is if Parallax makes the P3 dev board. That one can have a P2 on it. Would be useful for other things too.
@Baggers, I recall you going back to an earlier update. Does that work? I won't get to mine until tonight.
When you do a Ctrl-G from PNut, does it recognize the DE2-115 w/5 cogs and 128KB hub RAM? And do you have the 2.5" x 2.75" blue HSMC adapter board from Parallax that is marked "Terasis_DE2_115"? You would connect your VGA cable to the Parallax adapter board, not the one built into the DE2-115 base board.
pnut.exe:
What does Ctl-G do?
What does Ctl-D do?
Do you have a list of pnut commands?
Thanks
SETX - what bits are moved?
INCPAT/DECPAT - what do these do?
All,
Been working thru the instruction changes required to my P2 Debugger.
Here are a few changes...
movi/movd/movs -> seti/setd/sets - and there is a new setx instruction.
I use SHR #n WZ,WC,NR in a number of places
Now to look at the test style instructions
I knew there would be a few gotchas with the NR but we are way better of with the new set of instructions!
If you look at the items in the menu bar across the top of the applications, they're all in there.
SETX is for the five D bits between SETD and SETI.
INCPAT goes to the next-higher bit pattern with the same number of '1' bits (%10110 becomes %11001, then %11010, then %11100). DECPAT goes to the next-lower (reverse direction).
I'll get all the instructions documented soon.
I had missed Ctl-G in the Run menu. My board is not connected.
Chip,
Now that the SETF,MOVF instructions have been removed, we no longer have incremental indexing of bytes in within a LONG.
Have you considered a SETN instruction to modify the n-value in the following instructions.
In a previous post I mentioned an issue when using INDx++ in a WAITVID instruction while multi-tasking.
This was solved byte using a SETINDx ++1 after the WAITVID instruction.
The new FPGA code seems to be having trouble with this arrangement and the effect is no or bad video signal.
I am now using SETD instructions to modify the WAITVID instruction.
This part was quite simple, but I had decided to use P1 instructions where possible.
Now I need to change the instruction decode tables etc.
Note "wait" is now a pnut reserved word and cannot be used for a pasm dat label. Thought it was worth posting this info.
P2_InstructionsSEQ_20131127.spin
Do you mean other than P2 ? as in P2.5 ?
Over at Microchip, they call anything with legs a 'PIC', which lets them boast about sales volumes etc, when really they have many different uC cores, swept under that one umbrella. ARM are a bit the same.
re ozprops post #73 above and a possible SETN instruction to set the "n/nn/nnn" fields...
These are the instructions that have n, nn & nnn in their opcodes & WZ fields... You will note that only the instructions GETWORD/SETWORD, WAITPEQ and WAITPNE have opcodes that have "1" bits in the 6th nibble (other than "n" bits). If these instruction opcodes were swapped with TESTB, WRBYTE/WRWORD and SQRT64/QSINCOS so that they had a "0" bits in those bits, then SETNIB D,[#]S,#6 could be used to set the "n/nn/nnn" bits (on a proviso the user had the nibble msb unused bits set as zeros).
This way we would not require a SETN instruction. I realise this probably upsets some of the grouping of instructions that simplifies logic (like TESB, TESTN, TEST, CMP...)
You'll see that for GETNIB/SETNIB/GETBYTE/SETBYTE, there are leading 0's on nibble #6 of the encoding. The idea is that you can do a 'SETNIB inst,value,#6' to make self-modifying code.
For GETWORD/SETWORD, there is only one 'n' bit that needs modifying and something like 'SETBC inst,#24' can handle the modification.
About WAITVID, note that its immediate D value can range from 0..$DFF because of special WAITVID instruction encoding.
Do these statements address the issues you were having?
How would it not require a SETN instruction? Are you saying we could get rid of it, somehow?
Okay, I understand. I'll look at your recommendation to see how it would fit.
In the previous FPGA version I used the following code
WAITVID INDB,MYCOLOR SETINDB ++1In the new FPGA this does not work,no or bad video signal.
If I remove the SETINDB instruction the video works again,but obviously without indexing is incorrect.
I'm still doing some testing on this.
I'm also chasing a issue with the replacement of POPAR,POPBR
POPBR S1 POPBR S2 POPB s3This reads 2 longs then indexes back 1 step. This doesn't seem to work on the new FPGA.
PNut seems to accept these KEYWORDS without error.
I know RDAUX replaces some of these instructions, but I still haven't got a replacement to work yet.
I keep going and see what I find.
Great work on the update.
Cheers
Brian
I'll look into the INDx issue in the morning. The encoding has changed, but if you are using PNut, it should take care of that for you.
About POPBR: it is different than before. It used to be that the 'R' indicated reverse pointer movement (SPx++ vs --SPx). Now, all POPs are --SPx and all PUSHes are SPx++, regardless of the 'R'. The 'R' now means that instead of the address, it will use !address, or 255-address. The 'R' makes reverse addressing. If you read the AUX section of the Prop2_Docs.txt, it will explain everything about this.
For PASM code loaded with F11 use ORGH $E00 instead of ORGH $E80
ROM Monitor entry address has changed
' Usage: cognew($6E4, rx_pin << 9 + tx_pin) 'start monitor in new cog
Thanks Chip
Edit: POPxR changes from docs
POPAR D alias for 'RDAUX D,!--SPA'
POPBR D alias for 'RDAUX D,!--SPB'
PUSHAR D/# alias for 'WRAUX D/#,!SPA++'
PUSHBR D/# alias for 'WRAUX D/#,!SPB++'
Yikes! I didn't write those properly. The idea is there, but the syntax is not correct. They should read:
POPAR D alias for 'RDAUXR D,--SPA'
POPBR D alias for 'RDAUXR D,--SPB'
PUSHAR D/# alias for 'WRAUXR D/#,SPA++'
PUSHBR D/# alias for 'WRAUXR D/#,SPB++'
I'll change these in the morning. Thanks for posting these.
The new DE0-Nano FPGA code is running but my P2 Debugger is not working yet - it compiles ok. I will try just booting into the monitor straight away and see if that helps.
Yes, it recognises the DE2-115 w/5 cogs and 128KB hub RAM
I'll try it again later tonight, as I'm out to do a talk about making games to a load of 6th form art students.
@potatohead, yeah, I meant to try going back, but never got chance, will do it tonight!