fastspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

1343537394058

Comments

  • ersmith wrote: »
    Reinhard wrote: »
    @ersmith
    I understand, that is not necessary to implement sin() and cos() in fastspin.
    Therefore we have the cordic - unit.
    But is it possible to implement asin() and acos() ?
    or does someone know a way to calculate these functions with the available means?
    I need this for a 'hot' project.
    Reinhard

    I think you could implement asin() and acos() in terms of the CORDIC xy to polar conversion. That is, acos(x) is the angle t for which cos(t) = x, so it's the angle you get when you convert (x, sqrt(1-x^2)) to polar coordinates (if x is in the appropriate quadrant, and is between 0 and 1). You do have to do some sanity checking and have code to handle negatives and such, but that's the basic idea. asin() is similar.

    I do that and it works perfect.
    				// phi2 = acos (res1)
    				res2 = sqrt(1.0 - res1 * res1);
    				__asm{
    				qvector		res1,res2
    				getqx		t1
    				getqy		t2	
    				};	
    				phi2 = t2 * CORDIC_RESOLUTION;
    
    I never use t1 in the C - Programm.
    How I see in the pasm file, fastspin do this:
    	qvector	_main_res1_0014, result1
    	getqy	arg01
    	calla	#__system___float_fromint
    
    this is very good, also we can floats pass to the asm - block.
    THX
  • Reinhard wrote: »
    ersmith wrote: »
    Reinhard wrote: »
    @ersmith
    I understand, that is not necessary to implement sin() and cos() in fastspin.
    Therefore we have the cordic - unit.
    But is it possible to implement asin() and acos() ?
    or does someone know a way to calculate these functions with the available means?
    I need this for a 'hot' project.
    Reinhard

    I think you could implement asin() and acos() in terms of the CORDIC xy to polar conversion. That is, acos(x) is the angle t for which cos(t) = x, so it's the angle you get when you convert (x, sqrt(1-x^2)) to polar coordinates (if x is in the appropriate quadrant, and is between 0 and 1). You do have to do some sanity checking and have code to handle negatives and such, but that's the basic idea. asin() is similar.

    I do that and it works perfect.
    				// phi2 = acos (res1)
    				res2 = sqrt(1.0 - res1 * res1);
    				__asm{
    				qvector		res1,res2
    				getqx		t1
    				getqy		t2	
    				};	
    				phi2 = t2 * CORDIC_RESOLUTION;
    
    I never use t1 in the C - Programm.
    How I see in the pasm file, fastspin do this:
    	qvector	_main_res1_0014, result1
    	getqy	arg01
    	calla	#__system___float_fromint
    
    this is very good, also we can floats pass to the asm - block.
    THX

    Be careful with using floats in assembly, not very many instructions actually operate on floating point values. Even with the --fixed option to FlexGUI you should make sure that the instructions do what you want with 16.16 fixed point values; for example some of the CORDIC operations use 0.32 fixed point.
  • Eric,
    Chip has added a new feature called "addpins" to his Pasm2 for the purpose of encoding consecutive pins to the immediate value at least. He's used it in his latest flash_loader.spin2 - https://forums.parallax.com/discussion/comment/1488247/#Comment_1488247

  • I'm seeing something that should give an error, but doesn't...

    I removed the CON section definition for nco_baud from a code.
    This line should now give an error, but it doesn't:
    wxpin ##nco_baud, #TX_PIN      'set tx bit period
    
  • Funny, when I include the above file as an object in another file, it gives the error about nco_baud….
  • For the lazy out there (pointing at myself), is there a binary distro for Raspberry Pi available?
  • evanh wrote: »
    Chip has added a new feature called "addpins" to his Pasm2 for the purpose of encoding consecutive pins to the immediate value at least. He's used it in his latest flash_loader.spin2 - https://forums.parallax.com/discussion/comment/1488247/#Comment_1488247

    Looks like "a addpins b" is syntactic sugar for "a | (b<<6)". I can add that to Spin, but it won't work in inline assembly for C or BASIC.
    Rayman wrote: »
    I'm seeing something that should give an error, but doesn't...

    I removed the CON section definition for nco_baud from a code.
    This line should now give an error, but it doesn't:
    wxpin ##nco_baud, #TX_PIN      'set tx bit period
    

    It's rather difficult to diagnose without any context. I'm guessing that line is in inline assembly inside a method that wasn't used, in which case, that's a feature, not a bug -- inline assembly isn't parsed until the method is actually compiled, and if it's never used it'll never be compiled.
    octetta wrote: »
    For the lazy out there (pointing at myself), is there a binary distro for Raspberry Pi available?

    Perhaps from @DavidZemon 's build server?
  • This was pure asm that I just added a stop and start spin section to the top of.

    I put stop first so that it doesn’t do anything if ran alone.

    I suppose that technically means that the asm is never run if ran alone.

    But, that is not the intent...
    The intent is to call start from another spin file...
  • ersmith wrote: »
    Looks like "a addpins b" is syntactic sugar for "a | (b<<6)".
    Yep, not hard to edit.

    I wonder if Chip is going to do that for other multi-field situations like HUBSET, WRPIN, COGINIT ... the streamers are quite a handful.

  • octetta wrote: »
    For the lazy out there (pointing at myself), is there a binary distro for Raspberry Pi available?

    Perhaps from @DavidZemon 's build server?

    I'd taken a cursory look there and didn't see a successful build after 500ms of looking. Digging a little deeper, I found an older build that did succeed (4.0.0-beta).

    The current version makefile is failing at the make clean target... tonight I'll try building locally to see if it's a CI error or some weird RPi error and share findings here.

    Thanks to everyone here who makes my short attention span work on the prop possible.
  • octetta wrote: »
    octetta wrote: »
    For the lazy out there (pointing at myself), is there a binary distro for Raspberry Pi available?

    Perhaps from @DavidZemon 's build server?

    I'd taken a cursory look there and didn't see a successful build after 500ms of looking. Digging a little deeper, I found an older build that did succeed (4.0.0-beta).

    The current version makefile is failing at the make clean target... tonight I'll try building locally to see if it's a CI error or some weird RPi error and share findings here.

    Thanks to everyone here who makes my short attention span work on the prop possible.

    Yea... I've slacking pretty bad in keeping the build configurations up-to-date. I'll try to take another look soon and get it going again.
  • DavidZemon wrote: »
    octetta wrote: »
    octetta wrote: »
    For the lazy out there (pointing at myself), is there a binary distro for Raspberry Pi available?

    Perhaps from @DavidZemon 's build server?

    I'd taken a cursory look there and didn't see a successful build after 500ms of looking. Digging a little deeper, I found an older build that did succeed (4.0.0-beta).

    The current version makefile is failing at the make clean target... tonight I'll try building locally to see if it's a CI error or some weird RPi error and share findings here.

    Thanks to everyone here who makes my short attention span work on the prop possible.

    Yea... I've slacking pretty bad in keeping the build configurations up-to-date. I'll try to take another look soon and get it going again.

    Seeing all the work in setting up the CI system, I'd never call you a slacker...

    Just a note, I went ahead and pulled the latest spin2cpp (4.1.2-beta-ea965163) from GitHub to my RPi and it builds clean.

    It's beyond me what in the CI path is failing though... let me know if I can test anything here for you though.

    -joe

  • octetta wrote: »
    DavidZemon wrote: »
    octetta wrote: »
    octetta wrote: »
    For the lazy out there (pointing at myself), is there a binary distro for Raspberry Pi available?

    Perhaps from @DavidZemon 's build server?

    I'd taken a cursory look there and didn't see a successful build after 500ms of looking. Digging a little deeper, I found an older build that did succeed (4.0.0-beta).

    The current version makefile is failing at the make clean target... tonight I'll try building locally to see if it's a CI error or some weird RPi error and share findings here.

    Thanks to everyone here who makes my short attention span work on the prop possible.

    Yea... I've slacking pretty bad in keeping the build configurations up-to-date. I'll try to take another look soon and get it going again.

    Seeing all the work in setting up the CI system, I'd never call you a slacker...

    Just a note, I went ahead and pulled the latest spin2cpp (4.1.2-beta-ea965163) from GitHub to my RPi and it builds clean.

    It's beyond me what in the CI path is failing though... let me know if I can test anything here for you though.

    -joe

    Thanks, I'll do that.
  • RaymanRayman Posts: 11,053
    edited 2020-01-29 - 18:41:05
    I think I'm seeing something wrong here, but maybe I'm just doing something wrong...
    These two codes should do the same thing, but they don't... The first one doesn't work right.
    Anybody see the error?

    This one broke:
                setq    #200
                wrlong  ptrb,ptra
    

    This one works:
                rep     @.end,#200
                wrlong  ptrb,ptra++
    .end
    

    I'm just trying to write the value in ptrb to several consecutive longs starting at address in ptra...
  • Never mind, I see the problem now...
    setq advances both ptrb and ptra….
  • Block copy vs block fill. :)

    The REP will cycle every 9 sysclocks. If you decremented it'll cycle every 7 sysclocks. The following will fill a longword every 3 sysclocks:
    		rep	@.end, #25
    		wrlong	ptrb, ptra[3]
    		wrlong	ptrb, ptra[6]
    		wrlong	ptrb, ptra[1]
    		wrlong	ptrb, ptra[4]
    		wrlong	ptrb, ptra[7]
    		wrlong	ptrb, ptra[2]
    		wrlong	ptrb, ptra[5]
    		wrlong	ptrb, ptra++[8]
    .end
    
    Obviously needs size increments of 32 bytes though.

    Another option is have a small empty space in the cog and repeatedly block copy that. With the extra stalls it may not be all that much faster.
  • If the FIFO is free, how would REPing WFLONG perform?
  • evanhevanh Posts: 9,638
    edited 2020-01-30 - 00:35:44
    Lol, yeah, that'd work best.
    		wrfast	#0, ptra
    		rep	@.end, #200
    		wflong	ptrb
    .end
    		rdfast	#0, #0
    
  • Ok, maybe this is an actual problem here:

    I just made this little Spin routine:
    PUB VGA_Print(c)|oldCols,oldRows  'patch to make original VGA_Demo work
        oldCols:=cols
        oldRows:=rows
        Print(c)
        Cols:=oldCols
        rows:=oldRows
    

    Compiler doesn't like these last two lines...
    Gives this error: error: Internal Error: emitting move to immediate
  • Oops, I see the problem... rows and cols are constants...
  • Rayman wrote: »
    Compiler doesn't like these last two lines...
    Gives this error: error: Internal Error: emitting move to immediate

    That error message should be more informative (as you noticed later, it's because of an assignment to a constant). I'll get it to print something like "error: assignment to constant `row'" instead.

    Thanks,
    Eric
  • Got another strange error when I copied "Graphics_Demo" code into my tile driver test...

    I'm sure there are errors, especially with the buffers not yet being defined and such.
    But, the strange thing is that it gives me four error messages, all the same.
    They all point to the last line of the files (which happens to be blank) and says:
    "Unable to determine size of array"
  • I see the error it is referring to now...
    There are lines like this in a var section.
    byte  x[lines]
    
    But, I hadn't yet copied over the CON section with "lines".

    Of course, that's an error, just not sure why it pointed to the last line of the file...

  • Rayman wrote: »
    I see the error it is referring to now...
    There are lines like this in a var section.
    byte  x[lines]
    
    But, I hadn't yet copied over the CON section with "lines".

    Of course, that's an error, just not sure why it pointed to the last line of the file...

    The technical reason it's pointing to the last line of the file is that it doesn't know for sure that the constant "lines" isn't defined until it's scanned the whole file (Spin allows CON and VAR to be mixed in any order). But it's still puzzling, because normally it does save line number info for variable declarations, and uses that saved info. When I tried it just now it did print the correct line number for the array. There must be a case where it's getting the saved info wrong. Are you able to share a repro case?

    In many situations we should be able to print the name of the array, and that would be helpful, so I can at least add that.
  • It's probably more trouble that it's worth to fix this...
    This was a badly broken example...
    It'd also take me some time to go back to where it was broke...
  • I was just looking into the documentation for what exactly COGNEW and COGINIT do with the "Parameter"...

    Is this spelled out anywhere?

    There is no PAR register anymore... Does it go to PTRA?
  • Rayman wrote: »
    I was just looking into the documentation for what exactly COGNEW and COGINIT do with the "Parameter"...

    Is this spelled out anywhere?

    There is no PAR register anymore... Does it go to PTRA?

    Yes, it goes to PTRA on P2. It's documented in Chip's "Parallax Propeller 2 Documentation" Google document.
  • RaymanRayman Posts: 11,053
    edited 2020-01-31 - 16:31:25
    Sorry, I meant for the Spin versions of these (when starting assembly).
    I don't think that is described anywhere...
  • Rayman wrote: »
    Sorry, I meant for the Spin versions of these (when starting assembly).
    I don't think that is described anywhere...

    Chip is still writing the Spin2 documentation, I think. But anyway, the Spin versions do the same thing as the assembly versions, both on P1 (putting the parameter in PAR) and P2 (putting the parameter in PTRA).
  • Eric,
    I'm trying to pass a small auto array to inline assembly. But the pointer still seems to be a hub address.
    {
    	long data[10] = {1,2,3,4,5,6,7,8,9,10};
    	long *addr = data;
    	int len = sizeof(data) / 4 - 1;
    	
    	printf( "addr = %lx, len = %d\n", addr, len );
    
    	__asm { ... }
    }
    
    The print is giving me values above 0x1000. What's wrong?
Sign In or Register to comment.