Here's another bug that was driving me crazy...
I did a cut and paste job on this CASE statement.
It appears that having a second case 1 messed up the first case 1.
A bit surprised that happened...
case op
0: 'cmd0 'idle
EndCmd()
waitms(10)
return
1: 'cmd1 'voltage check
TriStateClocks(5) 'do 5 clocks with MOSI tristated
r1:=Read(8) 'get first 8 bits of response
cmd1response:=Read(32) 'get 32 bit response
r3:=Read(8) 'get lsat 8 bits of response
EndCmd() 'bring cs high
waitms(10)
return
2: 'get card ID (CID)
TriStateClocks(5) 'do 5 clocks with MOSI tristated
repeat i from 0 to 17-1 'get 17 byte response
cmd2response[i]:=Read(8)
EndCmd() 'bring cs high
return
1: 'cmd3 'set RCA
TriStateClocks(5) 'do 5 clocks with MOSI tristated
r1:=Read(8) 'get first 8 bits of response
cmd3response:=Read(32) 'get 32 bit response
r3:=Read(8) 'get lsat 8 bits of response
EndCmd() 'bring cs high
waitms(10)
return
Can you declare arrays as local variables like this?
PUB SendCMD(op,parm)|o[6],i,c,r1,r3
'Send command and sometimes get response
'first, need to calculate CRC7
o[0]:=$40+op
o[1]:=(parm>>24)&$FF
o[2]:=(parm>>16)&$FF
o[3]:=(parm>>8)&$FF
o[4]:=(parm>>0)&$FF
o[5]:=0
I thought you could, but it doesn't seem to work...
That code compiles fine for me. Why do you say it doesn't work?
Can you declare arrays as local variables like this?
PUB SendCMD(op,parm)|o[6],i,c,r1,r3
'Send command and sometimes get response
'first, need to calculate CRC7
o[0]:=$40+op
o[1]:=(parm>>24)&$FF
o[2]:=(parm>>16)&$FF
o[3]:=(parm>>8)&$FF
o[4]:=(parm>>0)&$FF
o[5]:=0
I thought you could, but it doesn't seem to work...
That's odd. I was sure I had done that myself with Spin1.
I think I had the same problem before. Constants in C are just normal variables that can't be changed. So they sit in HUB ram and
mov y,##x
is not allowed. You have to use a #define for x. Or maybe there is a trick telling the compiler that the expression after ## is constant and can be evaluated at compile time.
But back to your original point, wouldn't it be much easier to use a long variable and modify that, rather than poking around in the bits of two instructions?
mov foo, my_runtime_const
...
my_runtime_const
long 0
Still 2 longs, but now you just have to fix up one place (@my_runtime_const) and there are no bit shifts necessary.
Really? I just love having the ## option. Makes working on code much easier and definitely more readable...
Yeah, wastes two cycles and you can't reuse the same constant across multiple instructions. But surely more readable.
I remember LFT's ol' PLASMA P1 assembler has a ##, too, but in lieu of an AUGS instruction, it automatically allocates variables at the end of the program (or wherever you want, really).... Why has no one copied this feature yet? (altough IDK what operator would be used. ### seems a bit much)
The use of ## is very handy but one thing to keep in mind are looking out for any ## within skip sequences due to the extra hidden instruction generated. Overlooking one of those is a great way to break things as I found out the hard way yesterday
The use of ## is very handy but one thing to keep in mind are looking out for any ## within skip sequences due to the extra hidden instruction generated. Overlooking one of those is a great way to break things as I found out the hard way yesterday
- Added {++cog} and {++lut} to force functions into COG or LUT
- Made ORG in Spin2 fcache the asm
- Enabled fcache by default for P2
- Moved P2 FCACHE to second half of LUT
- Changed symbol resolution so Spin symbols are case insensitive in C
- Dramatically improved parsing of large initializer lists
- Accepted large addresses for jump instructions in inline assembly.
- Fixed C builtin function definitions for _wypin, _wrpin, etc.
- Fixed some cases where user code might be optimized when it shouldn't
- Used ZEROX/SIGNX for sign extension on P2
- Improved handling of floating point constants
- Improved warning messages for indirect jumps
- Reduced namespace clutter (accidental Spin influences) in C and BASIC
There are good arguments both ways for conflicts between global and local variables.
On the one hand, allowing you a local with any name at all means you can write a function without worrying about what global variable names there might be (so for example you can cut and paste functions between objects and the function will still work properly in its new place).
On the other hand, if you forget and try to use the global in a function that already has a local with that name, you won't get what you want.
I like the possibility to use local variables with same name as global ones.
Perhaps the compiler can issue a warning with variable name, function name and line number when this happens.
- Added {++cog} and {++lut} to force functions into COG or LUT
How does this work? I haven't found it in the docs.
Edit: There's a new document "general.pdf"
- Enabled fcache by default for P2
- Moved P2 FCACHE to second half of LUT
I worried that this could break my manual LUT optimization (see thread "fast floating point") but fortunatelly it still works. Can I override the default (locally) if I need all the LUT ram free? (--fcache is global)
- Improved handling of floating point constants
I can confirm this works, now. Constant subexpressions are pre-calculated at compile time.
It looks like the new default is not use fcache unless instructed to do so. I now get a warning for every function with inline assembly saying that FCACHE is disabled, hubexec will be used.
PS: Version 4.2.0 fresh from master branch moments ago.
Could it be that the function "round" vanished? I get an error "Symbol round is of a type not handled by PASM output yet" but the program had compiled without error with older versions. I haven't found a round function in math.h or anywhere else.
It looks like the new default is not use fcache unless instructed to do so. I now get a warning for every function with inline assembly saying that FCACHE is disabled, hubexec will be used.
PS: Version 4.2.0 fresh from master branch moments ago.
Hmmm, looks like there's a bug in the code that's supposed to automatically copy inline asm to fcache. That must have crept in at the last minute . I'll try to get it fixed, but in the meantime if you want your inline asm to run from fcache you'll have to give an explicit fcache size with --fcache=240 or something similar.
(fcache still works for Spin code without an explicit --fcache, but for some reason the inline asm code is not recognizing that it's there.)
Could it be that the function "round" vanished? I get an error "Symbol round is of a type not handled by PASM output yet" but the program had compiled without error with older versions. I haven't found a round function in math.h or anywhere else.
I don't think round() has ever been available in C. For now you could put a #define round(x) _float_round(x) in your file. That should be in math.h, but I don't see it there in any recent version.
Comments
I did a cut and paste job on this CASE statement.
It appears that having a second case 1 messed up the first case 1.
A bit surprised that happened...
That code compiles fine for me. Why do you say it doesn't work?
I was trying things like
where x is a constant...
But, couldn't get anything to work...
Why would you want to manually do the "##" instead of letting the assembler do it?
If you are trying to move a constant into y you need a # on the s operand in the mov instruction
mov y,#x
I was trying to modify the code from Spin with updated values before launching...
BTW: How do you get that assembly view?
I tried looking at the p2asm, but all the PASM2 code got turned into a binary blob...
In the end, I just created a new variable (cog register) and modified it from Spin instead.
I tried a bunch of different ways to do the manual "##", but nothing worked... Maybe I forgot a "#".
Anyway, problem solved for now...
Yeah, wastes two cycles and you can't reuse the same constant across multiple instructions. But surely more readable.
I remember LFT's ol' PLASMA P1 assembler has a ##, too, but in lieu of an AUGS instruction, it automatically allocates variables at the end of the program (or wherever you want, really).... Why has no one copied this feature yet? (altough IDK what operator would be used. ### seems a bit much)
BTW: Can I program P1 in Spin2 now? Sounds like it. That might be interesting...
demo.c needs an update to remove clkset()?
dgately
In fastspin yes, you can build Spin2 programs for P1, as long as you don't use any P2 hardware specific features (like anything smartpin related).
I like the possibility to use local variables with same name as global ones.
Perhaps the compiler can issue a warning with variable name, function name and line number when this happens.
How does this work? I haven't found it in the docs.
Edit: There's a new document "general.pdf"
I worried that this could break my manual LUT optimization (see thread "fast floating point") but fortunatelly it still works. Can I override the default (locally) if I need all the LUT ram free? (--fcache is global)
I can confirm this works, now. Constant subexpressions are pre-calculated at compile time.
PS: Version 4.2.0 fresh from master branch moments ago.
Hmmm, looks like there's a bug in the code that's supposed to automatically copy inline asm to fcache. That must have crept in at the last minute . I'll try to get it fixed, but in the meantime if you want your inline asm to run from fcache you'll have to give an explicit fcache size with --fcache=240 or something similar.
(fcache still works for Spin code without an explicit --fcache, but for some reason the inline asm code is not recognizing that it's there.)
I don't think round() has ever been available in C. For now you could put a #define round(x) _float_round(x) in your file. That should be in math.h, but I don't see it there in any recent version.