These are a weird thing on Propeller. I have been bitten by the min and max not really being min and max a few times.
I see the need for the limit versions, but the names are just wrong. Min and max universally (everywhere but Propeller) means give me the min or max of the two operands.
It's frustrating that MIN and MAX are quite literally named backwards of what they actually do.
From the manual:
MIN Value1, <#> Value2
Result: Greater of unsigned Value1 and unsigned Value2 is stored in Value1.
MAX Value1, <#> Value2
Result: Lesser of unsigned Value1 and unsigned Value2 is stored in Value1.
Chip,
Why oh why did you do this?????
I really think that for P2, we should fix this. The P2 PASM is already very different from P1, so it's not a big deal.
Yes, that certainly is backwards and it does need fixing.
If new names are assigned for P2, then P1 Spin can pick those up too, and the older (wrong) ones can be deprecated.
ie still work in old source, but all new code uses the operands that actually do what they say.
I'm wondering what work is left to be done on the FPGA before freezing the design and starting chip synthesis. I know Chip wants to get the P2 Spin bytecode interpreter running to see if any tweaking needs to be done there. It seems like this can be accomplished by porting the P1 Spin interpreter, and modifying it to run efficient on the P2.
Another thing to be done if for everyone to re-run the stuff that they've done with previous versions of the FPGA. This will help to uncover potential areas that may not run as efficiently as before, or may not even work anymore. Others may feel like me, and are reluctant to do this because the FPGA may change again. So it would be nice to get assurances that this really is the final FPGA, except for some minor fixes that may be needed.
It seems like the two-stage loader needs to be implemented before the FPGA can be declared final. This is the way we will be using the actual silicon, so it should be tested with the FPGA before finalizing the design.
IIt seems like the two-stage loader needs to be implemented before the FPGA can be declared final. This is the way we will be using the actual silicon, so it should be tested with the FPGA before finalizing the design.
Is there documentation on how the ROM loader works?
IIt seems like the two-stage loader needs to be implemented before the FPGA can be declared final. This is the way we will be using the actual silicon, so it should be tested with the FPGA before finalizing the design.
Is there documentation on how the ROM loader works?
I think the ROM loader ideally needs a separate thread, and a separate .DOC
There's nothing much to write, being simple and serial based (either text or hex).
Jmg was loading it from a small micro ....
There are still quite some details around supported Bauds and Auto baud schemes, and the Boot Tree decisions/delays, as well as the Pin mapping.
The UART transport layer is straightforward.
FWIR, Chip planned to nudge the RCFast to MIN of 20MHz, rather than typical, and the UART Autobaud improved to I think close to 2MBd.
Small MCUs can manage 1~2MBd commonly, with some capable of 3~4MBd
I did some code for one-pin loading from a sub-40c MCU, but I'm not sure of the final outcome of 1-2-3-4 pin boot.
There's nothing much to write, being simple and serial based (either text or hex).
Jmg was loading it from a small micro, OzPropDev from a terminal. Search the forums for prop_hex or prop_txt which throws up the code sent
Has anybody written a stand-alone program that will load the P2? The protocol looks simple, but the program would also need to reset the P2 and establish a serial link before the boot loader switches to the flash chip. Can programs be burned into the flash chip? Basically I'm looking for the same kind of functionality that the P1 loaders provide.
There's nothing much to write, being simple and serial based (either text or hex).
Jmg was loading it from a small micro, OzPropDev from a terminal. Search the forums for prop_hex or prop_txt which throws up the code sent
Has anybody written a stand-alone program that will load the P2? The protocol looks simple, but the program would also need to reset the P2 and establish a serial link before the boot loader switches to the flash chip. Can programs be burned into the flash chip? Basically I'm looking for the same kind of functionality that the P1 loaders provide.
I will do that once I have a description of the ASCII protocol. I've seen scattered examples of it in forum threads but not a description of it. I've sent Chip email asking for one.
I will do that once I have a description of the ASCII protocol. I've seen scattered examples of it in forum threads but not a description of it. I've sent Chip email asking for one.
In the Prop2 DOCs, under the heading BOOT PROCESS, there is some info.
Autobaud is using ">"
loader commands include Prop_Chk, Prop_Hex, Prop_Txt (64b)
Half duplex is via a suffix '*', but there seems no fast-ping (single char, or ">"+CharPing) ?
( "?" is always 10ms in the docs )
ie on systems with variable reset exit delays, the host has no simple means to 'poll until exits reset'
I guess you can sent repeated strings of "> Prop_Chk 0 0 0 0", and wait for the 15 char echo ?
If the Prop executes a software reset, it's not clear how the boot-serial server can know that ?
For normal bench use, I think you can use a UART with 2 handshake lines to
a) reset the P2
b) with 2 resistors, control the "pull-up on SPI_CS" test, to select SPI or UART boots
For flashing (UART -> Flash PGM), I think you first download a UART2SPI-pgm stub, then "~" launches that.
I think the Verilog is DONE, barring any bug fixes needed.
The ROM booter code may get some minor changes, but the protocol should stay the same. For example, I need to add the PRNG seeding from the ADC to the ROM booter.
I think the Verilog is DONE, barring any bug fixes needed.
The ROM booter code may get some minor changes, but the protocol should stay the same. For example, I need to add the PRNG seeding from the ADC to the ROM booter.
It may need some tweaks around Reset exit handling.
Looking more at the existing ping, of "send repeated strings of "> Prop_Chk 0 0 0 0", and wait for the 15 char echo ?"
- one issue I see here is the">" works fine, provided that is the first Char P2 sees.
However, what if the P2 reset-exit is delayed so it thinks some other char, is Autobaud ?
You could resolve that with an echo on autobaud ">",(ie sending host merely repeats ">") but now there is a simplex/duplex issue.
If it does not have two Autobaud chars, maybe it needs
">"+Char for AutoBaud, Duplex,
">"+Char("*"?) for Autobaud, Half-duplex (one pin)
Where the trigger chars are selected so reset-exit anywhere in either RX char, is safe.
("*" does not look great, with 0x2A value ?)
and both forms echo reply of one char after second char.
A second area is around host-loaders, and watchdog resets.
Here, the host needs to know P2 did a self-reset.
An IO pin with SW pulldown, could signal to the host by floating hi on reset & then host pulses P2 RST.
I'm sure this has been discussed before, but I'm not sure I like or understand the LOC syntax...
Using ##@ appears to work for me everywhere except on LOC.
These things appear to work the same:
loc ptra,#@RomFont1
loc ptra,#RomFont1
But, wouldn't it be better if this worked:
loc ptra,##@RomFont1
The LOC instruction (and a few others) contains a 20-bit field. No need for ## (AUGx).
Edit: For a little more information clarification, "#label" and "#@label" are identical for labels defined in an ORGH section. The only place you must use a "#@" is when you want the address in hub memory of a label defined in the ORG section. Of course, if you are calling something like WRLONG and want to sepecify a hub address over $1FF, you then must use "##label" or "##@label".
But there is one exception. There are six instructions that contain a 20-bit address field. These do not require a preceding AUGx instruction, so you would still only use "#label" or "#@label" with these. Look at the end of Chip's spreadsheet to see which instructions are in this set.
In truth, PNUT could probably be updated to make "##" benign for those instructions. I could see how someone might want to use "##@label" for all hub label references, just for consistency sake.
Comments
this limit Min/Max is (next to <=,>=) the biggest pain of Spin.
Enjoy!
Mike
Unfortunately, on the P1 it's also called MAX/MIN.
I see the need for the limit versions, but the names are just wrong. Min and max universally (everywhere but Propeller) means give me the min or max of the two operands.
Just have to remember that Limit Maximum == Take Minimum...
From the manual:
MIN Value1, <#> Value2
Result: Greater of unsigned Value1 and unsigned Value2 is stored in Value1.
MAX Value1, <#> Value2
Result: Lesser of unsigned Value1 and unsigned Value2 is stored in Value1.
Chip,
Why oh why did you do this?????
I really think that for P2, we should fix this. The P2 PASM is already very different from P1, so it's not a big deal.
Yes, that certainly is backwards and it does need fixing.
If new names are assigned for P2, then P1 Spin can pick those up too, and the older (wrong) ones can be deprecated.
ie still work in old source, but all new code uses the operands that actually do what they say.
Another thing to be done if for everyone to re-run the stuff that they've done with previous versions of the FPGA. This will help to uncover potential areas that may not run as efficiently as before, or may not even work anymore. Others may feel like me, and are reluctant to do this because the FPGA may change again. So it would be nice to get assurances that this really is the final FPGA, except for some minor fixes that may be needed.
It seems like the two-stage loader needs to be implemented before the FPGA can be declared final. This is the way we will be using the actual silicon, so it should be tested with the FPGA before finalizing the design.
Jmg was loading it from a small micro, OzPropDev from a terminal. Search the forums for prop_hex or prop_txt which throws up the code sent
There are still quite some details around supported Bauds and Auto baud schemes, and the Boot Tree decisions/delays, as well as the Pin mapping.
The UART transport layer is straightforward.
FWIR, Chip planned to nudge the RCFast to MIN of 20MHz, rather than typical, and the UART Autobaud improved to I think close to 2MBd.
Small MCUs can manage 1~2MBd commonly, with some capable of 3~4MBd
I did some code for one-pin loading from a sub-40c MCU, but I'm not sure of the final outcome of 1-2-3-4 pin boot.
In the Prop2 DOCs, under the heading BOOT PROCESS, there is some info.
Autobaud is using ">"
loader commands include Prop_Chk, Prop_Hex, Prop_Txt (64b)
Half duplex is via a suffix '*', but there seems no fast-ping (single char, or ">"+CharPing) ?
( "?" is always 10ms in the docs )
ie on systems with variable reset exit delays, the host has no simple means to 'poll until exits reset'
I guess you can sent repeated strings of "> Prop_Chk 0 0 0 0", and wait for the 15 char echo ?
If the Prop executes a software reset, it's not clear how the boot-serial server can know that ?
For normal bench use, I think you can use a UART with 2 handshake lines to
a) reset the P2
b) with 2 resistors, control the "pull-up on SPI_CS" test, to select SPI or UART boots
For flashing (UART -> Flash PGM), I think you first download a UART2SPI-pgm stub, then "~" launches that.
The ROM booter code may get some minor changes, but the protocol should stay the same. For example, I need to add the PRNG seeding from the ADC to the ROM booter.
It may need some tweaks around Reset exit handling.
Looking more at the existing ping, of "send repeated strings of "> Prop_Chk 0 0 0 0", and wait for the 15 char echo ?"
- one issue I see here is the">" works fine, provided that is the first Char P2 sees.
However, what if the P2 reset-exit is delayed so it thinks some other char, is Autobaud ?
You could resolve that with an echo on autobaud ">",(ie sending host merely repeats ">") but now there is a simplex/duplex issue.
If it does not have two Autobaud chars, maybe it needs
">"+Char for AutoBaud, Duplex,
">"+Char("*"?) for Autobaud, Half-duplex (one pin)
Where the trigger chars are selected so reset-exit anywhere in either RX char, is safe.
("*" does not look great, with 0x2A value ?)
and both forms echo reply of one char after second char.
A second area is around host-loaders, and watchdog resets.
Here, the host needs to know P2 did a self-reset.
An IO pin with SW pulldown, could signal to the host by floating hi on reset & then host pulses P2 RST.
Using ##@ appears to work for me everywhere except on LOC.
These things appear to work the same:
But, wouldn't it be better if this worked:
The LOC instruction (and a few others) contains a 20-bit field. No need for ## (AUGx).
Edit: For a little more information clarification, "#label" and "#@label" are identical for labels defined in an ORGH section. The only place you must use a "#@" is when you want the address in hub memory of a label defined in the ORG section. Of course, if you are calling something like WRLONG and want to sepecify a hub address over $1FF, you then must use "##label" or "##@label".
But there is one exception. There are six instructions that contain a 20-bit address field. These do not require a preceding AUGx instruction, so you would still only use "#label" or "#@label" with these. Look at the end of Chip's spreadsheet to see which instructions are in this set.
In truth, PNUT could probably be updated to make "##" benign for those instructions. I could see how someone might want to use "##@label" for all hub label references, just for consistency sake.
Tried replacing the commented code with it, but doesn't work:
mGetTileColorSet call #mGetTileColorsetLong 'and mK,#%111 'get nibble number 'andn mGetNibT,##%111<<19 'shl mK,#19 'or mGetNibT,mK 'nop 'nop altgn mk mGetNibT getnib mcolorset,mb,#0 RETAnybody see what I'm doing wrong?
Seems ALTGN is only useful for a nibble array in cog ram.
Not so useful when nibble array is in HUB ram.
Actually, can do it like this:
call #mGetTileColorsetLong and mK,#%111 'get nibble number 'andn mGetNibT,##%111<<19 'shl mK,#19 'or mGetNibT,mK 'nop 'nop or mk,##mb<<3 altgn mk mGetNibT getnib mcolorset,mb,#0 RETGuess this is better than self-modifying code.
I needed a fast way to get the bit count in a nibble so I did this
BTW. In my "Prop2 interactive Debugger" it includes sample code that demonstrates ALTGN/ALTSN.
If there was one that worked on the BITx instructions, then couldn't it replace all the DIRx, OUTx, etc. instructions?
This is just a theoretical question, not actually asking for it...
Anyway, could you have an ALTBIT instruction that would replicate OUTH like this:
Could that work? The altbit taking the lower 6 bits of operand and putting them into BITH's source and adding the 7th bit to BITH's destination?
Just wondering...