flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler - Page 37 — Parallax Forums

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

• Posts: 456
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
• Posts: 4,952
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.
• Posts: 11,252
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

• Posts: 12,082
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
```
• Posts: 12,082
Funny, when I include the above file as an object in another file, it gives the error about nco_baud….
• Posts: 114
For the lazy out there (pointing at myself), is there a binary distro for Raspberry Pi available?
• Posts: 4,952
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?
• Posts: 12,082
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...
• Posts: 11,252
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.

• Posts: 114
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.
• Posts: 2,936
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.
• Posts: 114
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

• Posts: 2,936
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.
• Posts: 12,082
edited 2020-01-29 18:41
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...
• Posts: 12,082
Never mind, I see the problem now...
setq advances both ptrb and ptra….
• Posts: 11,252
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.
• Posts: 1,776
If the FIFO is free, how would REPing WFLONG perform?
• Posts: 11,252
edited 2020-01-30 00:35
Lol, yeah, that'd work best.
```		wrfast	#0, ptra
rep	@.end, #200
wflong	ptrb
.end
rdfast	#0, #0
```
• Posts: 12,082
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
• Posts: 12,082
Oops, I see the problem... rows and cols are constants...
• Posts: 4,952
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
• Posts: 12,082
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"
• Posts: 12,082
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...

• Posts: 4,952
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.
• Posts: 12,082
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...
• Posts: 12,082
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?
• Posts: 4,952
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.
• Posts: 12,082
edited 2020-01-31 16:31
Sorry, I meant for the Spin versions of these (when starting assembly).
I don't think that is described anywhere...
• Posts: 4,952
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).
• Posts: 11,252
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};