Thanks, Chip. Here are my final comments on the instruction set. Most suggestions are new, the others repeated for completeness. My thinking is that if one instruction must move, the set will have changed and might as well move some others and have done with it. Numbering is by ascending opcodes, not importance.
* = instruction moved or changed
1. TEST and others
Move as shown below, so that all three instructions that use S/!S, namely AND/ANDN and MOV/NOT and TEST/TESTN, have opcode bits [23:21] = 000/001, making the coding more consistent and harmonious.
Does not involve D (nor S), so out of place in with the registered D instructions. I think it could be moved in front of POLLINT, with bit 17 changed from 0 to 1 for POLLxxx and WAITxxx.
TonyB_, think in terms of what looks most sensible to programmers and tool makers. At this point, there are no huge gains to be gotten by simplifying decoding, as things are already compartmentalized behind the scenes. How it flows in peoples' minds is more important.
But what if avoiding names is promoting them? Maybe we should "beepbeepbeep" the word "Propeller" to make it the best known word in the world? What if HP outside the (electro-) technical world is expanded in the sense of PLATO
Happy new year !
I'm using - no I'm enjoying - tachyon with P1 and one thing I'm definitely missing is flow control. Although Peter stated above that there currently is no fiddling with newline delay and character delay on the P2, I'm sure in future there will be.
From my point of view the lack of flow control would avoid unmanned builds which is inconvenient in times of robots ...
Best regards,
proplem
I also use FL fast load once I have EASYFILE loaded so that everything is buffered into a temporary or named file and loaded from the file where it is not necessary for flow control. With TAQOZ in P2 ROM this should be possible since I have FAT32 already resident, all it needs is an SD card. One advantage of downloading to a named file is that it is also an easy way to transfer source code onto the card. Maybe some of the newer USB serial chips have proper flow control built into them because as we know you can't rely upon the O/S to do it.
I think I've got the documentation all up-to-date, including all CLKSET functions and the timeout modes in the smart pins.
Chip,
Changing the encoding of the selector bits to be at LSbit end will allow for the reset and write protect functions to be encoded as single instructions.
Eg:
CLKSET D/# - Configure global circuit selected by MSBs
%DDDD_DDMM_MMMM_MMMM_PPPP_CCSS_Exxx_xx10 Set clock generator mode
%0000_0000_0000_0000_0000_0001_0000_0000 Hard reset, reboots chip
%0000_0000_0000_0000_0000_000P_1000_0000 Set write-protect of last 16KB RAM to P
%0000_0000_0000_0000_RRLL_TTTT_T100_0000 Set filter R to length L and tap T
%DDDD_DDDD_DDDD_DDDD_DDDD_DDDD_DDDD_DDD1 Seed Xoroshiro128+ PRNG with D
I think I've got the documentation all up-to-date, including all CLKSET functions and the timeout modes in the smart pins.
Chip,
Changing the encoding of the selector bits to be at LSbit end will allow for the reset and write protect functions to be encoded as single instructions.
Eg:
CLKSET D/# - Configure global circuit selected by MSBs
%DDDD_DDMM_MMMM_MMMM_PPPP_CCSS_Exxx_xx10 Set clock generator mode
%0000_0000_0000_0000_0000_0001_0000_0000 Hard reset, reboots chip
%0000_0000_0000_0000_0000_000P_1000_0000 Set write-protect of last 16KB RAM to P
%0000_0000_0000_0000_RRLL_TTTT_T100_0000 Set filter R to length L and tap T
%DDDD_DDDD_DDDD_DDDD_DDDD_DDDD_DDDD_DDD1 Seed Xoroshiro128+ PRNG with D
What I don't like about that is that it makes setting the clock require ## for most cases. I think setting the clock is going to be the most common use of this instruction, so it needs to be the simplest.
Here is how I see the the use cases in order of descending frequency:
1) setting the clock (most common, as apps need to save power)
2) write-protecting the last 16KB of RAM (used once/twice? by OS-type software)
3) setting the filters (probably a one-time thing)
4) resetting the chip (this has got to be rare)
5) seeding the PRNG (done by boot ROM, no need after)
It would be nice to be able to set 160MHz PLL operation from a 20MHz crystal. That would require something like this:
%P_PPPD_DDDD_DMMM_MMMM_MMME_CCSS
CLKSET #%1111_1_10_11
That seems kind of messy, though, as it reorders the PLL config fields in a way that doesn't flow logically from left to right.
The way it is now is maybe fine, considering the alternatives.
It would be nice to be able to set 160MHz PLL operation from a 20MHz crystal. That would require something like this:
%P_PPPD_DDDD_DMMM_MMMM_MMME_CCSS
CLKSET #%1111_1_10_11
That seems kind of messy, though, as it reorders the PLL config fields in a way that doesn't flow logically from left to right.
The way it is now is maybe fine, considering the alternatives.
I've noticed E field can be derived from CC field. How about splitting up the PLL config from the clock selection:
CLKSET D/# - Configure global circuit selected by MSBs
%0000_0000_PPPP_DDDD_DDMM_MMMM_MMMM_CC10 Config clock PLL generator
%0000_0000_0000_0000_0000_0000_SS10_0000 Select clock source
%0000_0000_0000_0000_0000_0001_0000_0000 Hard reset, reboots chip
%0000_0000_0000_0000_0000_000P_1000_0000 Set write-protect of last 16KB RAM to P
%0000_0000_0000_0000_RRLL_TTTT_T100_0000 Set filter R to length L and tap T
%DDDD_DDDD_DDDD_DDDD_DDDD_DDDD_DDDD_DDD1 Seed Xoroshiro128+ PRNG with D
It would be nice to be able to set 160MHz PLL operation from a 20MHz crystal. That would require something like this:
%P_PPPD_DDDD_DMMM_MMMM_MMME_CCSS
CLKSET #%1111_1_10_11
That seems kind of messy, though, as it reorders the PLL config fields in a way that doesn't flow logically from left to right.
The way it is now is maybe fine, considering the alternatives.
I've noticed E field can be derived from CC field. How about splitting up the PLL config from the clock selection:
CLKSET D/# - Configure global circuit selected by MSBs
%0000_0000_PPPP_DDDD_DDMM_MMMM_MMMM_CC10 Config clock PLL generator
%0000_0000_0000_0000_0000_0000_SS10_0000 Select clock source
%0000_0000_0000_0000_0000_0001_0000_0000 Hard reset, reboots chip
%0000_0000_0000_0000_0000_000P_1000_0000 Set write-protect of last 16KB RAM to P
%0000_0000_0000_0000_RRLL_TTTT_T100_0000 Set filter R to length L and tap T
%DDDD_DDDD_DDDD_DDDD_DDDD_DDDD_DDDD_DDD1 Seed Xoroshiro128+ PRNG with D
But, what if you wanted the crystal oscillator running, but not the PLL, too? It takes extra power to run the PLL.
Hmm ... hadn't thought of that option. The E field can be put where you suggested at bit4. I can't say I saw any flow issues.
I'm going to keep it how I've currently got it. I'm part way through compiling FPGA images now, and I don't want to start over. It's of marginal worth, either way. I think what we have now is simplest.
But, what if you wanted the crystal oscillator running, but not the PLL, too? It takes extra power to run the PLL.
If you wanted a CMOS clock source, and no Xtal amplifier, that seems to be missing ?
Select of %CC=%01 is close, but has a signal on XO that is not strictly needed.
The closest to 'Halt and wait for reset' looks to be 20kHz Osc select ?
But, what if you wanted the crystal oscillator running, but not the PLL, too? It takes extra power to run the PLL.
If you wanted a CMOS clock source, and no Xtal amplifier, that seems to be missing ?
Select of %CC=%01 is close, but has a signal on XO that is not strictly needed.
The closest to 'Halt and wait for reset' looks to be 20kHz Osc select ?
If you drive a signal into XI, XO will output the opposite with CC=%01. There will be no loading caps. I figured the clock-input mode %01 could follow on XO to allow some custom C-loading for a lower-C crystal.
Yes. 20KHz would draw way less power than the quiescent leakage. That is the power-down mode.
I'm going to keep it how I've currently got it. I'm part way through compiling FPGA images now, and I don't want to start over. It's of marginal worth, either way. I think what we have now is simplest.
If you do revisit it then turning it into four separate instructions also seems sensible. One for the random seed, one for xtal/pll config, one for pin filters, and one for clock-select and reset and write-protect.
That would provide maximal immediate addressing and, being single operand, they don't consume any valuable encoding space.
* Streamer pins now wrap around for 16-and 32-bit data paths on upper 8-pin offsets
* AND/ANDN, TEST/TESTN, and SETPIV/SETPIX have swapped encodings
* SCLU/SCL have been renamed to SCA/SCAS
* CLKSET has been renamed to HUBSET
* New MODC/MODZ aliases for MODCZ
This is the latest (and I think darn-near final) Verilog. This is in OnSemi's hands now and they are developing their compilation scripts with it.
I also use FL fast load once I have EASYFILE loaded so that everything is buffered into a temporary or named file and loaded from the file where it is not necessary for flow control. With TAQOZ in P2 ROM this should be possible since I have FAT32 already resident, all it needs is an SD card. One advantage of downloading to a named file is that it is also an easy way to transfer source code onto the card. Maybe some of the newer USB serial chips have proper flow control built into them because as we know you can't rely upon the O/S to do it.
@Peter,
is this FL something like redirecting serial in into a temporary file on sdcard and then loading from that file so that compilarion/execution is delayed but save?
Maybe you can answer in the tachyon thread to keep others informed about this. Thanks!
I also use FL fast load once I have EASYFILE loaded so that everything is buffered into a temporary or named file and loaded from the file where it is not necessary for flow control. With TAQOZ in P2 ROM this should be possible since I have FAT32 already resident, all it needs is an SD card. One advantage of downloading to a named file is that it is also an easy way to transfer source code onto the card. Maybe some of the newer USB serial chips have proper flow control built into them because as we know you can't rely upon the O/S to do it.
@Peter,
is this FL something like redirecting serial in into a temporary file on sdcard and then loading from that file so that compilarion/execution is delayed but save?
Maybe you can answer in the tachyon thread to keep others informed about this. Thanks!
that is what Peter is saying above in other words.
Re new MODC/MODZ aliases, shouldn't flag writing be shown in the spreadsheet as compulsory, as with GETRND without D?
GETRND WC/WZ/WCZ
MODC c WC
MODZ z WZ
Also, how does the assembler know which of the two instructions called CALLD to assemble?
Flag writing is not compulsory, though one wouldn't use the instruction without WC/WZ. For self-modifying code, though, we should not make flag writing compulsory.
The assembler does some sleuthing to know which CALLD to use.
I haven't heard much since I put up v31. Is anyone using it?
I loaded it onto my Prop123a9 board and ran the blink demo. I also started reading the documentation for LLVM. It looks to be quite a steep learning curve.
Comments
Next, I'll put the instruction set to bed for, hopefully, the last time by pushing out the latest internal Verilog into v31.
After that, I have a lot of communicating to do with OnSemi.
And after that, I want to get back to Spin2.
That's a great idea. Do you think we could make it shorter, though? That's way better than MulticoreEnhancedRealtimeKelvinEscalatingLaptop.
https://docs.google.com/spreadsheets/d/12GWGrEmp72MUIBvoXWadjWwqngrgQRqh9eYq6XhpEYQ/edit?usp=sharing
Thanks, Chip. Here are my final comments on the instruction set. Most suggestions are new, the others repeated for completeness. My thinking is that if one instruction must move, the set will have changed and might as well move some others and have done with it. Numbering is by ascending opcodes, not importance.
* = instruction moved or changed
1. TEST and others
Move as shown below, so that all three instructions that use S/!S, namely AND/ANDN and MOV/NOT and TEST/TESTN, have opcode bits [23:21] = 000/001, making the coding more consistent and harmonious.
Before: After:
2. RDFAST and others
Move as shown, so that RDFAST/WRFAST opcodes differ by only one bit.
Before: After:
3. RFBYTE and others
Move as shown, so that RFVAR/RFVARS, RFBYTE/WFBYTE, RFWORD/WFWORD and RFLONG/WFLONG differ by the same single bit.
Before: After:
4. MODCZ and others
Does not involve D (nor S), so out of place in with the registered D instructions. I think it could be moved in front of POLLINT, with bit 17 changed from 0 to 1 for POLLxxx and WAITxxx.
Before: After:
5. STALLI and others
Move as shown so that TRGINTx/NIXINTx differ by same bit. Also, bit 17 changed from 0 to 1 due to MODCZ move.
Before: After:
6. MERGEB and another
Possibly move as shown, so that SPLITx/MERGEx are split, not merged!
Before: After:
Modified instructions.txt with above changes attached.
Whether or not any of the above are implemented, that's me finished with the instruction set!
I also use FL fast load once I have EASYFILE loaded so that everything is buffered into a temporary or named file and loaded from the file where it is not necessary for flow control. With TAQOZ in P2 ROM this should be possible since I have FAT32 already resident, all it needs is an SD card. One advantage of downloading to a named file is that it is also an easy way to transfer source code onto the card. Maybe some of the newer USB serial chips have proper flow control built into them because as we know you can't rely upon the O/S to do it.
Changing the encoding of the selector bits to be at LSbit end will allow for the reset and write protect functions to be encoded as single instructions.
Eg:
What I don't like about that is that it makes setting the clock require ## for most cases. I think setting the clock is going to be the most common use of this instruction, so it needs to be the simplest.
Here is how I see the the use cases in order of descending frequency:
1) setting the clock (most common, as apps need to save power)
2) write-protecting the last 16KB of RAM (used once/twice? by OS-type software)
3) setting the filters (probably a one-time thing)
4) resetting the chip (this has got to be rare)
5) seeding the PRNG (done by boot ROM, no need after)
It would be nice to be able to set 160MHz PLL operation from a 20MHz crystal. That would require something like this:
%P_PPPD_DDDD_DMMM_MMMM_MMME_CCSS
CLKSET #%1111_1_10_11
That seems kind of messy, though, as it reorders the PLL config fields in a way that doesn't flow logically from left to right.
The way it is now is maybe fine, considering the alternatives.
But, what if you wanted the crystal oscillator running, but not the PLL, too? It takes extra power to run the PLL.
I'm going to keep it how I've currently got it. I'm part way through compiling FPGA images now, and I don't want to start over. It's of marginal worth, either way. I think what we have now is simplest.
If you wanted a CMOS clock source, and no Xtal amplifier, that seems to be missing ?
Select of %CC=%01 is close, but has a signal on XO that is not strictly needed.
The closest to 'Halt and wait for reset' looks to be 20kHz Osc select ?
If you drive a signal into XI, XO will output the opposite with CC=%01. There will be no loading caps. I figured the clock-input mode %01 could follow on XO to allow some custom C-loading for a lower-C crystal.
Yes. 20KHz would draw way less power than the quiescent leakage. That is the power-down mode.
That would provide maximal immediate addressing and, being single operand, they don't consume any valuable encoding space.
WHAT's NEW:
* Streamer pins now wrap around for 16-and 32-bit data paths on upper 8-pin offsets
* AND/ANDN, TEST/TESTN, and SETPIV/SETPIX have swapped encodings
* SCLU/SCL have been renamed to SCA/SCAS
* CLKSET has been renamed to HUBSET
* New MODC/MODZ aliases for MODCZ
This is the latest (and I think darn-near final) Verilog. This is in OnSemi's hands now and they are developing their compilation scripts with it.
Please try it out, if you can.
Thanks!
Cheers
Now that sounds a lot like a milestone !!
is this FL something like redirecting serial in into a temporary file on sdcard and then loading from that file so that compilarion/execution is delayed but save?
Maybe you can answer in the tachyon thread to keep others informed about this. Thanks!
that is what Peter is saying above in other words.
Also, how does the assembler know which of the two instructions called CALLD to assemble?
Flag writing is not compulsory, though one wouldn't use the instruction without WC/WZ. For self-modifying code, though, we should not make flag writing compulsory.
The assembler does some sleuthing to know which CALLD to use.
Super! Glad you're on board.