Shop OBEX P1 Docs P2 Docs Learn Events
Propeller II update - BLOG - Page 212 — Parallax Forums

Propeller II update - BLOG

1209210212214215223

Comments

  • evanhevanh Posts: 15,126
    edited 2014-03-16 14:50
    Heater. wrote: »
    ... 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.
  • Heater.Heater. Posts: 21,230
    edited 2014-03-16 15:25
    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-03-16 15:29
    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.
  • Heater.Heater. Posts: 21,230
    edited 2014-03-16 15:39
    Clusso,
    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.
    Hear, hear!
  • potatoheadpotatohead Posts: 10,253
    edited 2014-03-16 17:08
    Yep. It's really special. Thanks :)
  • cgraceycgracey Posts: 14,133
    edited 2014-03-16 22:04
    Cluso99 wrote: »
    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.

    These required very little logic.
  • ozpropdevozpropdev Posts: 2,791
    edited 2014-03-16 22:13
    cgracey wrote: »
    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! :)
  • cgraceycgracey Posts: 14,133
    edited 2014-03-16 22:37
    Cluso99 wrote: »
    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.
  • msrobotsmsrobots Posts: 3,701
    edited 2014-03-16 22:39
    +1 on nice one.

    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...
  • cgraceycgracey Posts: 14,133
    edited 2014-03-16 22:46
    msrobots wrote: »
    +1 on nice one.

    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).
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2014-03-16 23:12
    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?
  • ozpropdevozpropdev Posts: 2,791
    edited 2014-03-16 23:18
    Hi Chip,

    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_num
    

    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?
  • cgraceycgracey Posts: 14,133
    edited 2014-03-16 23:19
    Roy Eltham wrote: »
    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!
  • cgraceycgracey Posts: 14,133
    edited 2014-03-16 23:28
    ozpropdev wrote: »
    Hi Chip,

    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_num
    

    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.

    These are pretty important functions, I think.
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-03-17 00:45
    cgracey wrote: »
    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.
    Quite useful :)
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-03-17 00:51
    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.
  • jmgjmg Posts: 15,140
    edited 2014-03-17 02:09
    cgracey wrote: »
    ... 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.
  • David BetzDavid Betz Posts: 14,511
    edited 2014-03-17 04:15
    cgracey wrote: »
    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.
    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?
  • cgraceycgracey Posts: 14,133
    edited 2014-03-17 10:55
    David Betz wrote: »
    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.
  • David BetzDavid Betz Posts: 14,511
    edited 2014-03-17 11:08
    cgracey wrote: »
    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.
    Yeah, you're probably right. In fact, this sort of thing isn't done often enough to have a dedicated instruction for it anyway.
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-03-17 11:15
    Hi Chip.

    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)
    cgracey wrote: »
    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.
  • Heater.Heater. Posts: 21,230
    edited 2014-03-17 12:11
    cluso99.
    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?

    It does not even work. What about "
  • David BetzDavid Betz Posts: 14,511
    edited 2014-03-17 12:20
    Heater. wrote: »
    cluso99.

    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?

    It does not even work. What about "
  • SapiehaSapieha Posts: 2,964
    edited 2014-03-17 12:22
    Them are for spare program not speed
  • ctwardellctwardell Posts: 1,716
    edited 2014-03-17 12:25
    Heater. wrote: »
    cluso99.

    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?

    It does not even work. What about "
  • potatoheadpotatohead Posts: 10,253
    edited 2014-03-17 12:31
    'twas my guess. It's getting both smaller, and likely more capable of something. :)

    Bill might be right too, and moving some monitor guts around may well lay the foundation for on-chip stuff.
  • SapiehaSapieha Posts: 2,964
    edited 2014-03-17 12:37
    Hi ctwardell.

    Not only monitor.
    But next all interpreters.


    ctwardell wrote: »
    Those are likely for the benefit of the monitor program.

    C.W.
  • Heater.Heater. Posts: 21,230
    edited 2014-03-17 12:38
    @David,
    All of the CHKxxx instructions seem like overkill and wasting transistors ..
    I agree. Worse still, boggling the mind of anyone checking over the instruction set.

    @Sapieha,
    Them are for spare program not speed
    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,
    Those are likely for the benefit of the monitor program.
    We have had such monitor programs since the dawn of computers. Never have they needed such a thing.
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-03-17 12:39
    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.
  • ctwardellctwardell Posts: 1,716
    edited 2014-03-17 12:51
    Heater. wrote: »
    @ctwardell,

    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.

    C.W.
Sign In or Register to comment.