Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1145146147148149151»

Comments

  • evanh, could you explain in more detail what you're suggesting? The ORG directive currently tells the assembler to go into cog mode, and it sets the starting cog address. What else should it do?
  • evanhevanh Posts: 5,913
    edited December 6 Vote Up0Vote Down
    I'm fine with ORG, that was just a passing remark. It's LOC that needs the work.

    EDIT: I'd call it a base address rather than start address. "Start" might be mistaken for start of execution.
    EDIT2: Hmm, base is wrong too, ORG is not a relative thing at all. Section origin then.

    Money is a placeholder for cooperation
  • I added a warning in p2asm when LOC is used with a relative address. I think that should be sufficient. Maybe PNut should add that as well.
  • Thanks.
    Money is a placeholder for cooperation
  • evanh wrote: »
    It's not base-relative but PC-relative. PC-relative only makes sense for actual branches.

    That really isn't true. One of the things chip made explicit early on was the fact that data can be intermingled with code.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • Dave Hein wrote: »
    I added a warning in p2asm when LOC is used with a relative address. I think that should be sufficient. Maybe PNut should add that as well.

    I still don't quite see the danger of using LOC with a relative address, at least one above $400. After this code:
       orgh $400
       loc pa, #@label  ' relative addressing
       loc pb, #\@label ' absolute addressing
       cogstop #0
    label
       long 1
    
    PA and PB should have the same value. Am I missing something?
  • PA will contain $40C-$400 = $C. PB will contain $40C.
  • I was wrong. PA will contain a value of 8. Here's the listing from p2asm:
                       dat
    00400                 orgh $400
    3: WARNING: Relative mode used with LOC instruction
    00400     fe900008    loc pa, #@label  ' relative addressing
    00404     fea0040c    loc pb, #\@label ' absolute addressing
    00408     fd640003    cogstop #0
    0040c              label
    0040c     00000001    long 1
    
    As I said before, the might be value in using the difference for position-independent code.
  • OK, I was wrong. I ran this under spinsim, and I got PA=$1020 and PB=$1030. This may be correct, or p2asm may be wrong, or spinsim might be wrong. I'll have to check the binary with PNut's binary.
  • ozpropdevozpropdev Posts: 2,314
    edited December 6 Vote Up0Vote Down
    Both PA/PB will contain $408 $40C

    Edit: typo
    Melbourne, Australia
  • Dave Hein wrote: »
    OK, I was wrong. I ran this under spinsim, and I got PA=$1020 and PB=$1030. This may be correct, or p2asm may be wrong, or spinsim might be wrong. I'll have to check the binary with PNut's binary.

    p2asm looks OK, it produces the same thing as fastspin does, and when I run the result on the FPGA both pa and pb have the same value. I've attached the code I used for testing: foo.bas is the original source, foo.spin2 is the raw PASM produced by fastspin, foo.lst is the listing file that p2asm produces when it compiles foo.spin2. The output is:
    $ bin/loadp2 foo.binary -t
    [ Entering terminal mode.  Press ESC to exit. ]
    getting values
    pa=1064 pb=     1064
    
    which is correct (1064 = $428, which is where the label ends up in memory).

    Note that there's a bug in fastspin 3.9.10 such that it cannot handle @ and \ in inline assembly. That's fixed in the current github sources, so you'll need to use those if you want to regenerate foo.spin2.
  • ozpropdevozpropdev Posts: 2,314
    edited December 5 Vote Up0Vote Down
    Checked in Pnut
     orgh $400
       loc pa, #@label  ' relative addressing
       loc pb, #\@label ' absolute addressing
       cogstop #0
    label
    
    shows PA = $8 PB = $40c
    00400- 08 00 90 FE 0C 04 A0 FE 03 00 64 FD 00 00 00 00   '..........d.....'
    

    but this code shows PA = $40C and PB = $40C
    orgh	$400
    	org
    	loc	pa,#@label
    	loc	pb,#\@label
    	cogstop	#0
    label
    
    
    shows
    00400- 0C 04 80 FE 0C 04 A0 FE 03 00 64 FD 00 00 00 00   '..........d.....'
    

    Edit: Pnut switches to absolute because the ORG directive causes a domain crossiing.






    Melbourne, Australia
  • ersmithersmith Posts: 2,471
    edited December 6 Vote Up0Vote Down
    ozpropdev wrote: »
    Checked in Pnut
     orgh $400
       loc pa, #@label  ' relative addressing
       loc pb, #\@label ' absolute addressing
       cogstop #0
    label
    
    shows PA = $8 PB = $40c
    00400- 08 00 90 FE 0C 04 A0 FE 03 00 64 FD 00 00 00 00   '..........d.....'
    

    I think you're confusing the instruction encoding with what is actually put in the register when the instruction executes. If you execute the "relative addressing" version of the loc instruction, the PC after the instruction ($404) is added to the offset ($8 in this case) to get the final value of $40c. In other words, at run time PA and PB will end up with the same value of $40c in them when the two instructions execute.

    (Try it!)
  • ersmith wrote: »
    ozpropdev wrote: »
    Checked in Pnut
     orgh $400
       loc pa, #@label  ' relative addressing
       loc pb, #\@label ' absolute addressing
       cogstop #0
    label
    
    shows PA = $8 PB = $40c
    00400- 08 00 90 FE 0C 04 A0 FE 03 00 64 FD 00 00 00 00   '..........d.....'
    

    I think you're confusing the instruction encoding with what is actually put in the register when the instruction executes. If you execute the "relative addressing" version of the loc instruction, the PC after the instruction ($404) is added to the offset ($8 in this case) to get the final value of $40c. In other words, at run time PA and PB will end up with the same value of $40c in them when the two instructions execute.

    (Try it!)

    WHAT ?!?!
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • hehe ... isn't it lovely ... come join me in my torment ... hahaha



    Money is a placeholder for cooperation
  • Cluso99 wrote: »
    ersmith wrote: »
    ozpropdev wrote: »
    Checked in Pnut
     orgh $400
       loc pa, #@label  ' relative addressing
       loc pb, #\@label ' absolute addressing
       cogstop #0
    label
    
    shows PA = $8 PB = $40c
    00400- 08 00 90 FE 0C 04 A0 FE 03 00 64 FD 00 00 00 00   '..........d.....'
    

    I think you're confusing the instruction encoding with what is actually put in the register when the instruction executes. If you execute the "relative addressing" version of the loc instruction, the PC after the instruction ($404) is added to the offset ($8 in this case) to get the final value of $40c. In other words, at run time PA and PB will end up with the same value of $40c in them when the two instructions execute.

    (Try it!)

    WHAT ?!?!

    Look at foo.spin2 and/or foo.lst that I posted a few pages back (that's foo.bas converted to PASM2 by fastspin). The relevant instructions are:
                       ' 
                       ' sub getlabelvals()
    00408              _getlabelvals
                       '   asm
    00408     fe90001c 	loc	pa, #@label
    0040c     fea00428 	loc	pb, #\@label
    00410     f6006df6 	mov	_var_00, pa
    00414     f6006ff7 	mov	_var_01, pb
                       '   paval = x
    00418     fc606c2b 	wrlong	_var_00, objptr
                       '   pbval = y
    0041c     f1045604 	add	objptr, #4
    00420     fc606e2b 	wrlong	_var_01, objptr
    00424     f1845604 	sub	objptr, #4
                       ' label:
    00428              label
    00428              _getlabelvals_ret
    00428     fd64002e 	reta
    
    Note that the first loc is encoded as $fe90001c (relative addressing) whereas the second loc is encoded as $fea00428 (absolute addressing). At runtime they both put $428 into the respective registers, as is proven by the program output.

    The reason is simple: the PC relative "loc" instruction adds the next PC (PC+4) to the offset to get the value to put into the register, just like a relative "jmp" adds the next PC to the offset to get the new PC. So the first loc, at address $408, adds $40c to the offset $1c to get the final value $428.

    Note that it isn't *just* the offset that is different in the two loc encodings, there's actually a bit in the instruction that says whether the offset is absolute or relative.

    @, so you may have to use fastspin or p2asm. But all 3 assemblers agree about the encoding of the LOC instructions, so this isn't some quirk of fastspin or p2asm, it's the way the hardware works.

  • evanhevanh Posts: 5,913
    edited December 6 Vote Up0Vote Down
    ersmith wrote: »
    The reason is simple: the PC relative "loc" instruction adds the next PC (PC+4) to the offset to get the value to put into the register, just like a relative "jmp" adds the next PC to the offset to get the new PC. So the first loc, at address $408, adds $40c to the offset $1c to get the final value $428.

    Oh, oops, I've not been examining the final register content ... and I was convinced I was too, damn ...

    Money is a placeholder for cooperation
  • I get $40C for both cases when running on the FPGA. However, spinsim seems to be confused. It produces $1020 and $1030. It's shifting the value up by 2 bits, which means it must think it's in the COG mode.

    If I move the routine to a different location other than $400 I get the correct value in the relative mode, but an incorrect value in the absolute mode. This kind of shows the value of having position-independent-code. It appears that my linker isn't adjusting the address for the absolution mode. It doesn't surprise me since I don't recall handling relocation for the LOC command.

    I'm going to take the warning print out for the LOC command.
  • I get $40C in both cases on silicon.
    Melbourne, Australia
  • evanhevanh Posts: 5,913
    edited December 6 Vote Up0Vote Down
    The specified ORG addresses are for the "label". There are actually three labels, one for each ORG case.
    ===================================================
     LOC/MOV syntax        PA register results
     from hubRAM         ORG $0F  ORGH $110  ORGH $600
    ===================================================
    loc  pa, #label     0000000f   00000110   00000600
    loc  pa, #@label    0000003c   00000110   00000600
    loc  pa, #\label    0000000f   00000110   00000600
    loc  pa, #\@label   0000003c   00000110   00000600
    mov  pa, ##label    0000000f   00000110   00000600
    mov  pa, ##@label   0000003c   00000110   00000600
    ===================================================
     LOC/MOV syntax        PA register results
     from cogRAM         ORG $0F  ORGH $110  ORGH $600
    ===================================================
    loc  pa, #label     000fffee   000003e9   00000600
    loc  pa, #@label    00000081   000003c8   00000600
    loc  pa, #\label    0000000f   00000110   00000600
    loc  pa, #\@label   0000003c   00000110   00000600
    mov  pa, ##label    0000000f   00000110   00000600
    mov  pa, ##@label   0000003c   00000110   00000600
    
    
    Money is a placeholder for cooperation
  • Here's code for one line:
    		loc     pa, #\@str1
    		call    #puts
    		loc     pa, #palette1
    		call    #itoh
    		call    #putsp
    		loc     pa, #palette2
    		call    #itoh
    		call    #putsp
    		loc     pa, #palette3
    		call    #itoh
    		call    #putnl
    
    Money is a placeholder for cooperation
  • evanhevanh Posts: 5,913
    edited December 6 Vote Up0Vote Down
    Apologies on the PC-relative complaint. I was way off there.

    There is still the bug in Pnut though. It is in the cogexec LOC instruction encoding for PC-relative encoding below absolute $400. I guess that's where Cluso came unstuck and got me digging.

    Money is a placeholder for cooperation
  • evanhevanh Posts: 5,913
    edited December 6 Vote Up0Vote Down
    Here's another one:
    I've just been experimenting with building some diagnostic code and discovered it would be nice to know if the caller code was from cogexec or hubexec. A third status bit in the stacked address maybe.

    In this case I'm wanting a subroutine to extract the encoding of the instruction prior to the call. If I don't know whether the caller was in cogexec at the time or not then I can't calculate the relative address from the call stack.

    EDIT: Ah, forgot that code can't execute below $400 in hubRAM. That should be enough ...

    EDIT2: And working source code:
    		pop     char                  'grab caller address
    		push    char                  'restack it
    
    		cmp     char, ##$400   wcz    'test if caller was cogexec or hubexec, C = borrow of (D - S)
    
    if_c		sub     char, #2              'was cogexec
    if_c		alts    char                  'MOV indirection - get register content of register number in "char"
    if_c		mov     pa, 0-0
    
    if_nc		sub     char, #8              'was hubexec
    if_nc		rdlong  pa, char
    
    
    Money is a placeholder for cooperation
  • evanhevanh Posts: 5,913
    edited December 6 Vote Up0Vote Down
    Here's the results of above:
     LOC/MOV syntax         ORG $00F           ORGH $00110         ORGH $00600
     from hubRAM         op-code  PA-data    op-code  PA-data    op-code  PA-data
    ==============================================================================
    loc  pa, #label     fe80000f 0000000f   fe800110 00000110   fe900198 00000600
    loc  pa, #@label    fe80003c 0000003c   fe800110 00000110   fe900174 00000600
    loc  pa, #\label    fe80000f 0000000f   fe800110 00000110   fe800600 00000600
    loc  pa, #\@label   fe80003c 0000003c   fe800110 00000110   fe800600 00000600
    mov  pa, ##label    f607ec0f 0000000f   f607ed10 00000110   f607ec00 00000600
    mov  pa, ##@label   f607ec3c 0000003c   f607ed10 00000110   f607ec00 00000600
    
     LOC/MOV syntax         ORG $00F           ORGH $00110         ORGH $00600
     from cogRAM         op-code  PA-data    op-code  PA-data    op-code  PA-data
    ==============================================================================
    loc  pa, #label     fe9fffe0 000ffff7   fe9003dc 000003f5   fe800600 00000600
    loc  pa, #@label    fe900070 00000090   fe9003b8 000003da   fe800600 00000600
    loc  pa, #\label    fe80000f 0000000f   fe800110 00000110   fe800600 00000600
    loc  pa, #\@label   fe80003c 0000003c   fe800110 00000110   fe800600 00000600
    mov  pa, ##label    f607ec0f 0000000f   f607ed10 00000110   f607ec00 00000600
    mov  pa, ##@label   f607ec3c 0000003c   f607ed10 00000110   f607ec00 00000600
    
    
    Money is a placeholder for cooperation
  • evanhevanh Posts: 5,913
    edited December 6 Vote Up0Vote Down
    Wow, that detail is needed. Pnut is making a mess of the PC-relative LOC encodings. Only six of the twelve PC-relative combinations above is correct. Even two of the hubexec encodings ($fe800110 is absolute encoding) is wrong because it is using absolute encoding below $400 in hubRAM where it should still be PC-relative.

    Or is that case intentional because hubexec can't go there?

    Money is a placeholder for cooperation
  • evanh wrote: »
    Wow, that detail is needed. Pnut is making a mess of the PC-relative LOC encodings. Only six of the twelve PC-relative combinations above is correct. Even two of the hubexec encodings ($fe800110 is absolute encoding) is wrong because it is using absolute encoding below $400 in hubRAM where it should still be PC-relative.

    Or is that case intentional because hubexec can't go there?
    LOC is also usable to obtain the hub address of a table, which can reside below or above hub $400.

    That is one of the problems I found - the hard way as I wasted a whole day trying to find a bug in my program.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
Sign In or Register to comment.