... The only little fly in the ointment just now is that Chip's PNUT is in x86 assembler and only available for Windows.
And Wine ... The program runs easy. Don't know about comms though, I don't have any hardware. Presumably it's a simple case of assigning a COM number in the Wine prefix data.
Yes it does run under Wine. I also did not get as far as seeing if the comms works. It's that fly in the ointment thing. I look forward to getting back to it.
Some really nice (general) discussion guys. I did notice one interesting item missing in all this...
We are learning the P2 while it is morphing. This gives us (the ones playing with the fpga emulation) a really intimate understanding of the P2. And with the aid of these discussions (especially the discussions leading to the new P2 features) understand the reasons behind the features too.
These intimate understanding of a chip's architecture takes ages (like it did on the P1) to understand. We still don't properly understand the video on the P1 - so we can exploit other abilities of the video logic for uses besides video. The same is currently true of the counters and video of the P2, and the pin functions too. But as far as the instruction set goes, we have been given a deep understanding by following the threads. We now have features such as hubexec mode, caches, aux memory, various call/push/pop, some with different LIFOs, and of course multi-task and multi-threads.
When the P2 ultimately arrives, we will have a fantastic head start on newcomers, and there will be some really interesting support software available, mostly done by us forumistas!
The only downside is currently you require a PC and Windows (or W emulation) to run pnut. IMHO this is something we can live with because otherwise we would impose a big delay - Chip is totally at home with the '86 assembler so we need to keep it that way for speed of changes.
Once the P2 settles down again (shortly now), I don't expect to see the radical instruction set opcodes changes we have seen over the past 3 months. Then the Tools can again proceed in the background.
As a final statement...
I feel really honoured to be able to participate in the development of the P2. I will be eternally indebted to Chip and Parallax for this unprecedented opportunity. Ray.
I feel really honoured to be able to participate in the development of the P2. I will be eternally indebted to Chip and Parallax for this unprecedented opportunity. Ray.
Chip, How is the fpga code coming along?
Did you manage to get it to compile to the Cyclone V or did you give up?
Did you get time to look at my verilog code for USB ? jmg fixed some of the syntax and helped with verilog
I didn't know how to express the input pins as pin[s[7:0]] and pin[s[7:0] | $01].
I glanced at it, but haven't understood it, yet.
As I was getting the FPGA images together, I remembered that the ROM Monitor was broken, since I changed the COGNEW/COGRUN parameter setup to a single long with two 16-bit fields (high word is a long pointer to variables (or just a 16-bit value), low word is a long pointer to code). In fixing the monitor, I've also been cleaning up on the code. There are now 4 modes: bYte, Word, loNg, and eXec. Exec is for hub-execution-mode perspective, where the address is 16 bits (the 18-bit hub address, shifted right by two), and the data is 32 bits. This mode makes it very apparent how hub exec works. I'm almost done with the new ROM.
I added a few new instructions, too:
PASSTXA/PASSTXB 'Loop until SERA/SERB transmit complete. In some cases, you just need to know when a transmission is complete.
CHKDEC D {WC} 'if D is "0".."9", convert to 0..9 and set C, otherwise leave D the same and clear C.
CHKHEX D {WC} 'if D is "0".."9"/"A".."F"/"a".."f", convert to 0..15 and set C, otherwise leave D the same and clear C.
CHKLET D {WC} 'if D is "A".."Z"/"a".."z", convert to "A".."Z" and set C, otherwise leave D the same and clear C.
CHKSYM D {WC} 'if D is "A".."Z"/"a".."z"/"_", convert to "A".."Z"/"_" and set C, otherwise leave D the same and clear C.
PASSTXA/PASSTXB 'Loop until SERA/SERB transmit complete. In some cases, you just need to know when a transmission is complete.
CHKDEC D {WC} 'if D is "0".."9", convert to 0..9 and set C, otherwise leave D the same and clear C.
CHKHEX D {WC} 'if D is "0".."9"/"A".."F"/"a".."f", convert to 0..15 and set C, otherwise leave D the same and clear C.
CHKLET D {WC} 'if D is "A".."Z"/"a".."z", convert to "A".."Z" and set C, otherwise leave D the same and clear C.
CHKSYM D {WC} 'if D is "A".."Z"/"a".."z"/"_", convert to "A".."Z"/"_" and set C, otherwise leave D the same and clear C.
I feel really honoured to be able to participate in the development of the P2. I will be eternally indebted to Chip and Parallax for this unprecedented opportunity. Ray.
I love working with all of you guys, too. What a neat direction things have taken over the last year!
It's great that we are living in a time when our interests and experiences can coalesce over thousands of miles, so that we can create new things to tickle our minds and hopefully, in the future, the minds of many others.
This will ease up any text to number conversation and things like menus/commands. (think about all those cogs waiting/parsing some mailbox)
now the other way around if this needs very little logic.
bytehex? --- produces "FF" out of 255 -- needs word as destination
wordhex? ---produces "FFFF" out of 65535 -- needs long as destination.
something similar useful for conversion to decimal as string. Maybe ? (divide source by 10 and store back then return remainder in dest ?)
Enjoy!
Mike
think about all those ser.dec() ser.hex() in spin and pasm...
One of you introduced a neat algorithm here for converting between binary and BCD, where a simple bit-shifting loop can realize either conversion, given that the core transform is available. That core transform, which works on nibbles, has been implemented in the BINBCD/BCDBIN instructions. You can actually chain longs together if you've got really large values, and do conversions of any length. I think humans, for whom decimal matters, only want to look at maybe six digits, anyway, with some magnitude suffix (uA, mV, MHz).
Chip,
Are those CHK* ones assuming ASCII? Also, Is it just checking the lowest 8bits of D? Or is it maybe treating D like four 8bit characters?
Also, CHKSYM is for symbols right? shouldn't that include numbers?
Did you have a look at the LSBZ D instruction?
Returns the lowest zero bit in D. (0 to 31)
C=1 Success,C=0 Fail (D=$FFFFFFFF)
Can be used as "local lock" to control resources i.e. register mapping.
Chip,
Are those CHK* ones assuming ASCII? Also, Is it just checking the lowest 8bits of D? Or is it maybe treating D like four 8bit characters?
Also, CHKSYM is for symbols right? shouldn't that include numbers?
It's checking the whole 32 bits for ASCII, making sure the top 25 bits are 0's and then evaluating the lower 7 bits.
You're right about the CHKSYM needing to allow digits, too!
Did you have a look at the LSBZ D instruction?
Returns the lowest zero bit in D. (0 to 31)
C=1 Success,C=0 Fail (D=$FFFFFFFF)
Can be used as "local lock" to control resources i.e. register mapping.
The amount of flags available can simply be set by setting upper bits initially.
If 6 flags are need simply use
MOV usage_reg,##$FFFFFFC0
The code above could be wrapped by TLOCK and TFREE if multi-tasking is used.
Thoights?
Yes! I've been thinking more about this.
I realized that ENCOD actually does this job, just with input bits reversed and inversed. I could redo this so that there would be four variants:
TOPZERO D,S/# 'get top zero bit position of S/# into D, C=1 if no bit with D=32
BOTZERO D,S/# 'get bottom zero bit position of S/# into D, C=1 if no bit with D=32
TOPONE D,S/# 'get top one bit position of S/# into D, C=1 if no bit with D=32
BOTONE D,S/# 'get bottom one bit position of S/# into D, C=1 if no bit with D=32
The only difference between all these is that inputs to the priority encoder may be reversed and/or inversed, with the output value being inversed if the input value was reversed.
As I was getting the FPGA images together, I remembered that the ROM Monitor was broken, since I changed the COGNEW/COGRUN parameter setup to a single long with two 16-bit fields (high word is a long pointer to variables (or just a 16-bit value), low word is a long pointer to code). In fixing the monitor, I've also been cleaning up on the code. There are now 4 modes: bYte, Word, loNg, and eXec. Exec is for hub-execution-mode perspective, where the address is 16 bits (the 18-bit hub address, shifted right by two), and the data is 32 bits. This mode makes it very apparent how hub exec works. I'm almost done with the new ROM.
I added a few new instructions, too:
PASSTXA/PASSTXB 'Loop until SERA/SERB transmit complete. In some cases, you just need to know when a transmission is complete.
CHKDEC D {WC} 'if D is "0".."9", convert to 0..9 and set C, otherwise leave D the same and clear C.
CHKHEX D {WC} 'if D is "0".."9"/"A".."F"/"a".."f", convert to 0..15 and set C, otherwise leave D the same and clear C.
CHKLET D {WC} 'if D is "A".."Z"/"a".."z", convert to "A".."Z" and set C, otherwise leave D the same and clear C.
CHKSYM D {WC} 'if D is "A".."Z"/"a".."z"/"_", convert to "A".."Z"/"_" and set C, otherwise leave D the same and clear C.
This can be done easily in sw, but it could be nice (after a release?)...
UCASE D WZ,WC
For converting bytes into printable versions for dumping memory.
Converts a-z -> A-Z; $00-$1F & $7F -> ".".
WZ could be used to zero bit 7 (top bit) else convert all with bit7=1 to ".".
C would be set if the char was converted to ".".
This would be nice to work on all 4 bytes of the long.
... I think humans, for whom decimal matters, only want to look at maybe six digits, anyway, with some magnitude suffix (uA, mV, MHz).
Instrumentation use may want to go above 6 digits, and 2^32 is ~ 9.5 decimal digits, and there are 64b results in a P2, so working on 64b would be good.
Bin-BCD does not really need to be blazingly fast, but being small buys code space.
As I was getting the FPGA images together, I remembered that the ROM Monitor was broken, since I changed the COGNEW/COGRUN parameter setup to a single long with two 16-bit fields (high word is a long pointer to variables (or just a 16-bit value), low word is a long pointer to code). In fixing the monitor, I've also been cleaning up on the code. There are now 4 modes: bYte, Word, loNg, and eXec. Exec is for hub-execution-mode perspective, where the address is 16 bits (the 18-bit hub address, shifted right by two), and the data is 32 bits. This mode makes it very apparent how hub exec works. I'm almost done with the new ROM.
I added a few new instructions, too:
PASSTXA/PASSTXB 'Loop until SERA/SERB transmit complete. In some cases, you just need to know when a transmission is complete.
CHKDEC D {WC} 'if D is "0".."9", convert to 0..9 and set C, otherwise leave D the same and clear C.
CHKHEX D {WC} 'if D is "0".."9"/"A".."F"/"a".."f", convert to 0..15 and set C, otherwise leave D the same and clear C.
CHKLET D {WC} 'if D is "A".."Z"/"a".."z", convert to "A".."Z" and set C, otherwise leave D the same and clear C.
CHKSYM D {WC} 'if D is "A".."Z"/"a".."z"/"_", convert to "A".."Z"/"_" and set C, otherwise leave D the same and clear C.
These required very little logic.
What about a version of CHKLET that just checks to see if a character is a letter but doesn't autoconvert it to uppercase for languages that are case sensitive?
What about a version of CHKLET that just checks to see if a character is a letter but doesn't autoconvert it to uppercase for languages that are case sensitive?
I was thinking the same thing. You could just redirect the result write to some other register (or work on a copy) and note the C flag.
I realized that ENCOD actually does this job, just with input bits reversed and inversed. I could redo this so that there would be four variants:
TOPZERO D,S/# 'get top zero bit position of S/# into D, C=1 if no bit with D=32
BOTZERO D,S/# 'get bottom zero bit position of S/# into D, C=1 if no bit with D=32
TOPONE D,S/# 'get top one bit position of S/# into D, C=1 if no bit with D=32
BOTONE D,S/# 'get bottom one bit position of S/# into D, C=1 if no bit with D=32
The only difference between all these is that inputs to the priority encoder may be reversed and/or inversed, with the output value being inversed if the input value was reversed.
UCASE D WZ,WC
For converting bytes into printable versions for dumping memory.
Converts a-z -> A-Z; $00-$1F & $7F -> ".".
WZ could be used to zero bit 7 (top bit) else convert all with bit7=1 to ".".
C would be set if the char was converted to ".".
This would be nice to work on all 4 bytes of the long.
Noooo.... This is a fine example of an instruction too far. "Jumping the shark".
It can be done in software easily enough. When are you ever going to need super fast upper case conversion?
heater & David,
Yes, I agree. Thanks for the reality check!
There are much better things to use the silicon for (if we have any left). After all, the only real savings is in a couple of longs because the conversion should be in a routine - and we have hubexec mode so those routines could be in hub if required.
We have had such monitor programs since the dawn of computers. Never have they needed such a thing.
Given that Chip mentioned these in the context of almost being done with the updated ROM, I would imagine he added then to free space in the ROM to squeeze in everything he wanted to include without increasing the size of the ROM.
Comments
And Wine ... The program runs easy. Don't know about comms though, I don't have any hardware. Presumably it's a simple case of assigning a COM number in the Wine prefix data.
We are learning the P2 while it is morphing. This gives us (the ones playing with the fpga emulation) a really intimate understanding of the P2. And with the aid of these discussions (especially the discussions leading to the new P2 features) understand the reasons behind the features too.
These intimate understanding of a chip's architecture takes ages (like it did on the P1) to understand. We still don't properly understand the video on the P1 - so we can exploit other abilities of the video logic for uses besides video. The same is currently true of the counters and video of the P2, and the pin functions too. But as far as the instruction set goes, we have been given a deep understanding by following the threads. We now have features such as hubexec mode, caches, aux memory, various call/push/pop, some with different LIFOs, and of course multi-task and multi-threads.
When the P2 ultimately arrives, we will have a fantastic head start on newcomers, and there will be some really interesting support software available, mostly done by us forumistas!
The only downside is currently you require a PC and Windows (or W emulation) to run pnut. IMHO this is something we can live with because otherwise we would impose a big delay - Chip is totally at home with the '86 assembler so we need to keep it that way for speed of changes.
Once the P2 settles down again (shortly now), I don't expect to see the radical instruction set opcodes changes we have seen over the past 3 months. Then the Tools can again proceed in the background.
As a final statement...
I feel really honoured to be able to participate in the development of the P2. I will be eternally indebted to Chip and Parallax for this unprecedented opportunity. Ray.
I glanced at it, but haven't understood it, yet.
As I was getting the FPGA images together, I remembered that the ROM Monitor was broken, since I changed the COGNEW/COGRUN parameter setup to a single long with two 16-bit fields (high word is a long pointer to variables (or just a 16-bit value), low word is a long pointer to code). In fixing the monitor, I've also been cleaning up on the code. There are now 4 modes: bYte, Word, loNg, and eXec. Exec is for hub-execution-mode perspective, where the address is 16 bits (the 18-bit hub address, shifted right by two), and the data is 32 bits. This mode makes it very apparent how hub exec works. I'm almost done with the new ROM.
I added a few new instructions, too:
PASSTXA/PASSTXB 'Loop until SERA/SERB transmit complete. In some cases, you just need to know when a transmission is complete.
CHKDEC D {WC} 'if D is "0".."9", convert to 0..9 and set C, otherwise leave D the same and clear C.
CHKHEX D {WC} 'if D is "0".."9"/"A".."F"/"a".."f", convert to 0..15 and set C, otherwise leave D the same and clear C.
CHKLET D {WC} 'if D is "A".."Z"/"a".."z", convert to "A".."Z" and set C, otherwise leave D the same and clear C.
CHKSYM D {WC} 'if D is "A".."Z"/"a".."z"/"_", convert to "A".."Z"/"_" and set C, otherwise leave D the same and clear C.
These required very little logic.
Nice one!
I love working with all of you guys, too. What a neat direction things have taken over the last year!
It's great that we are living in a time when our interests and experiences can coalesce over thousands of miles, so that we can create new things to tickle our minds and hopefully, in the future, the minds of many others.
This will ease up any text to number conversation and things like menus/commands. (think about all those cogs waiting/parsing some mailbox)
now the other way around if this needs very little logic.
bytehex? --- produces "FF" out of 255 -- needs word as destination
wordhex? ---produces "FFFF" out of 65535 -- needs long as destination.
something similar useful for conversion to decimal as string. Maybe ? (divide source by 10 and store back then return remainder in dest ?)
Enjoy!
Mike
think about all those ser.dec() ser.hex() in spin and pasm...
One of you introduced a neat algorithm here for converting between binary and BCD, where a simple bit-shifting loop can realize either conversion, given that the core transform is available. That core transform, which works on nibbles, has been implemented in the BINBCD/BCDBIN instructions. You can actually chain longs together if you've got really large values, and do conversions of any length. I think humans, for whom decimal matters, only want to look at maybe six digits, anyway, with some magnitude suffix (uA, mV, MHz).
Are those CHK* ones assuming ASCII? Also, Is it just checking the lowest 8bits of D? Or is it maybe treating D like four 8bit characters?
Also, CHKSYM is for symbols right? shouldn't that include numbers?
Did you have a look at the LSBZ D instruction?
Returns the lowest zero bit in D. (0 to 31)
C=1 Success,C=0 Fail (D=$FFFFFFFF)
Can be used as "local lock" to control resources i.e. register mapping.
'To allocate a block RESD #block_num LSBZ usage_reg SETB usage_reg,block_num SETMAP #0,block_num 'select register block 'release block CLRB block_usage,block_numThe amount of flags available can simply be set by setting upper bits initially.
If 6 flags are need simply use
The code above could be wrapped by TLOCK and TFREE if multi-tasking is used.
Thoights?
It's checking the whole 32 bits for ASCII, making sure the top 25 bits are 0's and then evaluating the lower 7 bits.
You're right about the CHKSYM needing to allow digits, too!
Yes! I've been thinking more about this.
I realized that ENCOD actually does this job, just with input bits reversed and inversed. I could redo this so that there would be four variants:
TOPZERO D,S/# 'get top zero bit position of S/# into D, C=1 if no bit with D=32
BOTZERO D,S/# 'get bottom zero bit position of S/# into D, C=1 if no bit with D=32
TOPONE D,S/# 'get top one bit position of S/# into D, C=1 if no bit with D=32
BOTONE D,S/# 'get bottom one bit position of S/# into D, C=1 if no bit with D=32
The only difference between all these is that inputs to the priority encoder may be reversed and/or inversed, with the output value being inversed if the input value was reversed.
These are pretty important functions, I think.
UCASE D WZ,WC
For converting bytes into printable versions for dumping memory.
Converts a-z -> A-Z; $00-$1F & $7F -> ".".
WZ could be used to zero bit 7 (top bit) else convert all with bit7=1 to ".".
C would be set if the char was converted to ".".
This would be nice to work on all 4 bytes of the long.
Instrumentation use may want to go above 6 digits, and 2^32 is ~ 9.5 decimal digits, and there are 64b results in a P2, so working on 64b would be good.
Bin-BCD does not really need to be blazingly fast, but being small buys code space.
I was thinking the same thing. You could just redirect the result write to some other register (or work on a copy) and note the C flag.
HASHWIDE D
XOR's the bytes in the current WIDE togeather, writing eight bit result to D.
If WZ is specified, and the result is 0, Z=1
Useful for:
- hash functions
- xor checksums
It will help your native Spin assembler/compiler
(the recent instructions you added are a dead giveaway that you have started working on it)
It can be done in software easily enough. When are you ever going to need super fast upper case conversion?
It does not even work. What about "
Bill might be right too, and moving some monitor guts around may well lay the foundation for on-chip stuff.
Not only monitor.
But next all interpreters.
@Sapieha, Yep, might save a bit of space. If any one remembers to use it. And who is doing such text processing in COG space anyway? We have room otherwise.
@ctwardell, We have had such monitor programs since the dawn of computers. Never have they needed such a thing.
Yes, I agree. Thanks for the reality check!
There are much better things to use the silicon for (if we have any left). After all, the only real savings is in a couple of longs because the conversion should be in a routine - and we have hubexec mode so those routines could be in hub if required.
Given that Chip mentioned these in the context of almost being done with the updated ROM, I would imagine he added then to free space in the ROM to squeeze in everything he wanted to include without increasing the size of the ROM.
C.W.