Prop2 FPGA files!!! - Updated 16 October 2017 - Version 24a

1747577798093

Comments

  • Rayman,
    Proptool & OpenSpin have the same limit. It's in the x86 compiler code.
  • Rayman wrote: »
    Just thinking about this alt stuff...

    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:
    'OUTH #43
    ALTBIT #43
    BITH OUTA,#0-0
    

    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...

    It could be made to work like that, but isn't what we already have better?
  • cgracey wrote: »
    .. but isn't what we already have better?
    Yes and in 2 clocks too.

    Melbourne, Australia
  • Was just curious about what else you could do with ALTR... Seems it gives an extra degree of freedom...

    Is the bus between hub and cog one bidirectional pipe or two unidirectional pipes?

    If it were two, seems you could make it read and write hub address at same time, right?
    ALTR OldHubLong
    WRLONG NewHubLong, HubAdd
    

    Just wondering...
    Prop Info and Apps: http://www.rayslogic.com/
  • This may be obvious but I guess you need to put the same conditional prefix on ALTx and AUGx instructions as well as the instruction they follow. Does it work to put a conditional just on AUGx or ALTx but not on the modified instruction? Does that prevent the modification?
  • Rayman wrote: »
    Was just curious about what else you could do with ALTR... Seems it gives an extra degree of freedom...

    Is the bus between hub and cog one bidirectional pipe or two unidirectional pipes?

    If it were two, seems you could make it read and write hub address at same time, right?
    ALTR OldHubLong
    WRLONG NewHubLong, HubAdd
    

    Just wondering...

    ALTR is for redirecting cog registers not hub.
    For example
    		mov	someplace,#outb
    
    		altr	someplace
    		add	r1,r2		'result is written to outb
    					'and r1 remains unchanged.
    


    Melbourne, Australia
  • David Betz wrote: »
    This may be obvious but I guess you need to put the same conditional prefix on ALTx and AUGx instructions as well as the instruction they follow. Does it work to put a conditional just on AUGx or ALTx but not on the modified instruction? Does that prevent the modification?
    AUGx is automatically generated by Pnut when needed.
    For example
    	if_c	mov	r1,##$ffffffff
    
    'pnut generates
    
    	if_c	augs	#$7ffffff
    	if_c	mov	r1,#$1ff
    

    If manually coded with a conditional on the AUGx/ALTx instruction its the same as any other instruction and is only executed if the condition is true.



    Melbourne, Australia
  • ozpropdev wrote: »
    David Betz wrote: »
    This may be obvious but I guess you need to put the same conditional prefix on ALTx and AUGx instructions as well as the instruction they follow. Does it work to put a conditional just on AUGx or ALTx but not on the modified instruction? Does that prevent the modification?
    AUGx is automatically generated by Pnut when needed.
    For example
    	if_c	mov	r1,##$ffffffff
    
    'pnut generates
    
    	if_c	augs	#$7ffffff
    	if_c	mov	r1,#$1ff
    

    If manually coded with a conditional on the AUGx/ALTx instruction its the same as any other instruction and is only executed if the condition is true.


    That's what I would have expected. Thanks for confirming.

  • Rayman wrote: »
    Was just curious about what else you could do with ALTR... Seems it gives an extra degree of freedom...

    Is the bus between hub and cog one bidirectional pipe or two unidirectional pipes?

    If it were two, seems you could make it read and write hub address at same time, right?
    ALTR OldHubLong
    WRLONG NewHubLong, HubAdd
    

    Just wondering...

    If the P2 buss is anything like the P1, then it's half-duplex.
  • cgraceycgracey Posts: 8,025
    edited March 18 Vote Up0Vote Down
    You can either read or write when your cog's hub opportunity comes around. You can't do both.
  • cgraceycgracey Posts: 8,025
    edited March 28 Vote Up0Vote Down
    Latest v17 FPGA files and doc's are posted at the top of this thread.

    Improved PRNG, now Xoroshiro128+.
    New _RET_ instruction prefix for automatic RETurn.
    New SKIP/SKIPF instructions for instruction skipping.
    New EXECF instruction for branching plus fast skipping in cog memory.
  • Ok, nice. We were a bit worried about MHz and/or consuming smart pins, but looks like those changes were relatively benign
  • Thanks Chip!
    Melbourne, Australia
  • All flavours of V17 FPGA images flashed Ok on all boards. :)
    Melbourne, Australia
  • ozpropdev wrote: »
    All flavours of V17 FPGA images flashed Ok on all boards. :)

    Thanks a lot for checking them all out.

    You can try out _ret_ now. I'm looking forward to getting back on the interpreter tomorrow.
  • Chip
    Another change to the docs.

    NOP is no longer an alias for "IF_0000 ROR 0,0" and now has its own opcode $00000000 = NOP
    :)
    Melbourne, Australia
  • ozpropdev wrote: »
    Chip
    Another change to the docs.

    NOP is no longer an alias for "IF_0000 ROR 0,0" and now has its own opcode $00000000 = NOP
    :)

    Okay. I changed that in the spreadsheet, but I haven'tlooked in the doc's, yet.
  • I take it that the instruction encodings have changed for v17. Has the layout of the instruction spreadsheet changed?
  • cgraceycgracey Posts: 8,025
    edited March 29 Vote Up0Vote Down
    David Betz wrote: »
    I take it that the instruction encodings have changed for v17. Has the layout of the instruction spreadsheet changed?

    The only changes were that RET/RETA/RETB (I=1) were folded into the CALL/CALLA/CALLB encodings (I = 0), which made room for SKIP/SKIPF/EXECF.

    The spreadsheet has been updated, but its layout is still the same.
  • cgracey wrote: »
    David Betz wrote: »
    I take it that the instruction encodings have changed for v17. Has the layout of the instruction spreadsheet changed?

    The only changes were that RET/RETA/RETB (I=1) were folded into the CALL/CALLA/CALLB encodings (I = 0), which made room for SKIP/SKIPF/EXECF.

    The spreadsheet has been updated, but its layout is still the same.
    Excellent! I have a program that parses the spreadsheet to produce instruction tables for gas.
  • There seems to be a problem with CALLD in the latest version. If I do "calld pa,#target" my program crashes if target is more than $400 bytes from the calling location. The PNut assembler uses the version of CALLD with the larger address range, but it shifts the address offset down by 2 bits. If target is less than $400 bytes from the calling location the assembler will use the other version of CALLD, and it works OK.
  • Dave Hein wrote: »
    There seems to be a problem with CALLD in the latest version. If I do "calld pa,#target" my program crashes if target is more than $400 bytes from the calling location. The PNut assembler uses the version of CALLD with the larger address range, but it shifts the address offset down by 2 bits. If target is less than $400 bytes from the calling location the assembler will use the other version of CALLD, and it works OK.

    Dave, can you please post the example?
  • jmgjmg Posts: 10,465
    Dave Hein wrote: »
    There seems to be a problem with CALLD in the latest version. If I do "calld pa,#target" my program crashes if target is more than $400 bytes from the calling location. The PNut assembler uses the version of CALLD with the larger address range, but it shifts the address offset down by 2 bits. If target is less than $400 bytes from the calling location the assembler will use the other version of CALLD, and it works OK.

    So the problem is PNut, and you can manually craft a correct CALLD > $400 ? (FPGA is ok ?)

  • Dave HeinDave Hein Posts: 5,295
    edited April 5 Vote Up0Vote Down
    The example is a bit long, but the problem shows up when calling the _clock routine. I added a "long 0[207+5]" statement to shift the position of _clock relative to the calling points at _CALL1 and _CALL2. If I insert less than 207 longs it uses the short version of CALLD, and it works OK. If I insert 207 or more longs it will use the long version of CALLD, and fails. Oddly enough, values of 207, 211, 215, etc. kind of work because the zeroes I'm inserting act as NOPs. values of 208, 209, 210, 212, etc. will fail.

    EDIT: The _clock routine is located at the end of the file.
  • SPAM^
  • cgraceycgracey Posts: 8,025
    edited April 5 Vote Up0Vote Down
    Dave Hein wrote: »
    There seems to be a problem with CALLD in the latest version. If I do "calld pa,#target" my program crashes if target is more than $400 bytes from the calling location. The PNut assembler uses the version of CALLD with the larger address range, but it shifts the address offset down by 2 bits. If target is less than $400 bytes from the calling location the assembler will use the other version of CALLD, and it works OK.

    I see the problem. It's in PNut.exe. I'll get this fixed.

    When the assembler sees the two LSBs of the relative address being %00, it errantly applies the ">>2" rule for the short CALLD version.

    This example works, but if you get rid of the "+1", it fails:
    dat
    	orgh	$400
    	calld	pa,#$804+1
    
  • Melbourne, Australia
  • jmgjmg Posts: 10,465
    ozpropdev wrote: »

    Did you mean that the code in this post still fails ?
    http://forums.parallax.com/discussion/comment/1401185/#Comment_1401185
    or did you mean the issue above, is not fixed ?
  • jmg wrote: »
    ozpropdev wrote: »

    Did you mean that the code in this post still fails ?
    http://forums.parallax.com/discussion/comment/1401185/#Comment_1401185
    or did you mean the issue above, is not fixed ?
    Oops, yes the code example in that thread still fails.

    Melbourne, Australia
Sign In or Register to comment.