upcoming fastspin changes

ersmith

There are some major changes coming to fastspin, and apply both toe Propeller 1 (P1) and Propeller 2 (P2). They're in the current github, and I'll put a binary up for my Patreons soon. The big new features are:

(1) Ability to place functions in COG memory (and eventually LUT memory on P2), e.g. we could write in the various languages

' Spin1 / Spin2
pub {++cog} sum(x, y) : r
  r := x+y

' BASIC
function for "cog" sum(x, y)
  return x+y
end function

// C
int sum(int x, int y) __attribute__(("cog")) {
  return x+y;
}

Obviously this will have to be used sparingly!

(2) FCACHE is now enabled by default for P2. This is a feature where small loops are copied to processor internal memory (LUT in the case of P2) before execution. This feature was already present on P1 and enabled at level -O2 for P2; now it's enabled at level -O1 (the default) for P2 as well.

(3) ORG/END blocks on inline assembly are loaded into FCACHE memory before execution. A similar feature is available in C (with "__asm volatile") and BASIC ("asm cpu").

(4) The symbol name resolution has been revised, so that symbol resolution takes place in the language of the file associated with the object. So Spin symbols will be case insensitive, even for references from C, and C symbols are case sensitive even for references from Spin (and non-lower case C symbols can be accessed now).

There are probably going to be many bugs associated with these new features, but if you'd like to try them out I'd encourage you to do so. Note that the Makefile dependencies don't seem to be quite right, and for this change (which hits some key internal files) you should do "make clean" before trying to build the new version.

David Betz

ersmith wrote: »

(4) The symbol name resolution has been revised, so that symbol resolution takes place in the language of the file associated with the object. So Spin symbols will be case insensitive, even for references from C, and C symbols are case sensitive even for references from Spin (and non-lower case C symbols can be accessed now).

Very nice! I can now access Spin methods with their mixed case names. Thanks!

ersmith

I've uploaded a FlexGUI/fastspin beta to my Patreon page for those who want a sneak peek. If everything remains stable I hope to make an official release later this week.

Mike Green

Thank you.

I wanted to report a problem with a warning message. I tend to use the 4-port serial driver for the P1. This sets up coroutines to handle the various optional features of the serial ports and FastSpin seems to choke on the JMPRET instructions used for this. Is there a way to turn off the warning? The warning messages tend to terminate my build scripts.

ersmith

I think the warnings are legitimate. For example, in "jmpret rxcode,txcode" the jump target at label "txcode" is written as an instruction. Almost always a jump in which the target is an instruction is the result of a typo (so usually the user meant to write "jmpret rxcode, #txcode"). In this particular case the author is doing something tricky (deliberately placing instructions that are never executed with particular values of the source field being used as data). So this code works, but it's non-obvious and many similar uses are mistakes.

The warnings can be fixed by following the direction in the warning, e.g changing "jmpret rxcode,txcode" to "jmpret rxcode,txcode+0" (or "txcode-0", or any expression at all really... although now that I think about it perhaps "txcode-0" is better, in analogy to 0-0).

Another way to fix the warnings would be to change the first 8 instructions from things like:

rxcode  if_never        mov     rxcode,#receive        ' set source fields to initial entry points
txcode  if_never        mov     txcode,#transmit       ' these will be modified by the jmpret mechanism
...

to

rxcode long receive ' upper bits are 0, so never executed
txcode long transmit ' ditto
...

In this case fastspin will notice that the jump target is data, rather than code, and hence be happy with its use in an indirect jump.

ersmith

Hmm, actually I spoke too soon; one of the warnings (about a jmpret whose target is itself a jmpret) shouldn't have been issued; the code was supposed to let that go without warning, but there were a couple of mistakes in that check. That's fixed in github now, and it gives an easier way of fixing the errors: just change all instructions that say "if_never mov" to be "if_never jmpret", which I think is actually a better example of the intent of the code anyway.

Thanks for this code example, Mike.

Tracy Allen

The source field of all 12 jmpret instructions in fullDuplexSerial4pnf are patched during the pasm initialization,
so in more recent versions I've used
jmpret receive, 0-0
with the appropriate ddd field and so on for all 12 instances. The way the patches are done, only the serial ports that have been enabled are included, and others that are not enabled are locked out.

Was the error thrown by the process of patching the jmpret's, or by fact that the jmprets point to instructions? The Prop2 doesn't have a jmpret, does it?

As to the initial 9 locations that are used as the vectors, any of the forms will work, so long as they get the initial targets into the source field. The if_never is unnecessary, as any of the following will work.

rxcode  if_never        mov     rxcode,#receive        ' source field is the initial entry point
or
rxcode          mov     rxcode,#receive        ' source field is the initial entry point
or 
rxcode          long receive        ' source field is the initial entry point, executes as nop

They all function the same way, so it is an aesthetic preference.

Placing the vector locations at the top of the cog is an unnecessary trick. Program operation does not depend on it, and they can be placed in a more conventional manner at the end of the code. However, having them at the beginning makes it easier in a way to visualize the action. Both the source and dest fields of all the jmpret instructions have numbers from 0 to 8 to indicate which vector is used as the program detects data and jumps around through the coroutines.

Cluso99

Two things to note
There is no if-never condition. It is used for the _RET_ condition.
A long may not necessarily be a NOP, but execute whatever bits are there. IIRC it’s something like a ROL 0,0 that is treated as a NOP.
Sorry. Thought it was a P2 thread I was reading. Must have been asleep at the wheel.

Tracy Allen

if_always is the default




Sorry ersmith, I don't want to derail this thread.

max72

First of all sorry it it's the wrong thread but I would signal the following;
I downloaded FlexGUI and tried to compile a P1 program that uses GPS_IO_mini, and the compiler throws an error about two lines using this symbol: <>=
Propeller tool compiles it fine
I attach the object
Massimo

ersmith

max72 wrote: »

First of all sorry it it's the wrong thread but I would signal the following;
I downloaded FlexGUI and tried to compile a P1 program that uses GPS_IO_mini, and the compiler throws an error about two lines using this symbol: <>=
Propeller tool compiles it fine
I attach the object
Massimo

Thanks for the bug report.

repeat while Rx <>= "$"

is another way of writing

repeat while Rx := Rx <> "$"

Fastspin should have accepted the first form but didn't. I'll fix that bug; but I suspect actually that the original code was meant to read

repeat while Rx <> "$"

since Rx is set immediately afterwards, there's no need to update it.

max72

Thanks,
I agree, the assignment is useless.
Anyway it's kind of funny the first compile threw the error. I guess it's a seldom used command :-)
Thanks again,
Massimo