...Besides, after Microchip's native PIC mnemonics, anything else looks good!
-Phil
My favorite was "BTFSC", which meant "bit test file register and skip if clear". In our assembly language, we renamed that to "SB". For OR, I think they had "IORWF" which meant "inclusive-OR W with file register".
I can see uses for testing perhaps, but I think I'd rather have better open drain support, and use an extra line of code for the random pin case, than vice versa.
There also has to be a finite silicon cost to DRVRND & FLTRND ?
I can see uses for testing perhaps, but I think I'd rather have better open drain support, and use an extra line of code for the random pin case, than vice versa.
There also has to be a finite silicon cost to DRVRND & FLTRND ?
What would be needed for better open-drain support? You can always copy C or !C to a DIR bit via DIRC or DIRNC. Is there more needed?
What would be needed for better open-drain support? You can always copy C or !C to a DIR bit via DIRC or DIRNC. Is there more needed?
Perhaps that DIRC, DIRNC needs an alias into the BITxx group, to make it clearer you can float via CY ?
Would that be BITFC, BITFNC or BITCF, BITNCF ?
I can see a use where the streamer is opendrain, which I think would need a pin-config for open drain (as many MCUs have now)
Maybe that is already there ?
What would be needed for better open-drain support? You can always copy C or !C to a DIR bit via DIRC or DIRNC. Is there more needed?
Perhaps that DIRC, DIRNC needs an alias into the BITxx group, to make it clearer you can float via CY ?
Would that be BITFC, BITFNC or BITCF, BITNCF ?
I can see a use where the streamer is opendrain, which I think would need a pin-config for open drain (as many MCUs have now)
Maybe that is already there ?
BITxx are general register bit operations, while DIRxx/OUTxx/FLTxx/DRVxx are DIR and OUT bit operations whose index spans 64 bits (DIRA/DIRB and OUTA/OUTB). Just use those instructions, I think.
BITxx are general register bit operations, while DIRxx/OUTxx/FLTxx/DRVxx are DIR and OUT bit operations whose index spans 64 bits (DIRA/DIRB and OUTA/OUTB). Just use those instructions, I think.
Oops yes, slight brain fade here, only paying half attention, and getting confused with 8051 opcodes, where the same BIT opcodes apply across all of Pin IO space and Flags and user RAM Boolean scratch bits.
One thing I'd like to do before getting this out is maybe clear up some name-space conflicts.
NOT, AND, and OR are both PASM instructions and boolean operators. This is going to cause headaches.
How about if, for PASM, we renamed these instructions to NOTF, ANDF, ORF and XORF (F for 'function', let's say)? XORF is just there for consistency.
Any better idea?
If you have inline assembly, there's no need for builtin Spin functions for PASM; instead you could create an object that has them all, and the function names would then be in the object namespace. E.g.:
PUB notf(Dv, S) : r
ASM
NOT Dv, S
ENDASM
r := Dv
and then to use it do:
OBJ i : "instructions"
...
x := i.notf(x, y)
You could even have the "instructions" object built in to the interpreter and/or always loaded with a predefined name like "instr".
This is exactly what fastspin does for most of the Spin builtins corresponding to instructions, except that it puts the function definitions into global namespace for compatibility with Spin.
It seems like there is a lot of discussion on the new Spin syntax, operator names and other things that have no impact on the silicon. I thought the sudden urgency of getting Spin working on the P2 was to uncover potential issues with the hardware design before it goes out to synthesis. Changing Spin syntax and operator names doesn't do a thing toward that goal, and in fact only delays the silicon even more. I was hoping for a merry Chipmas this year, but it seems more and more doubtful when I see all the random tweaks that are suggested for New Spin.
1. Eliminate @@ -- not to mention the hideous @@@. Make @ mean "the address of", period, regardless of context. IOW, figure out the actual address at compile time, even if it means an extra compile pass or two, or maybe even a linking phase. In Spin, @ vs. @@ causes a lot of confusion, and neither is entirely adequate for the simple job they're supposed to perform.
Good idea, this is one place where breaking backwards compatibility with Spin would probably be worth it.
2. Add the ternary operator: condition ? eval_if_true : eval_if_false. Probably have to use ?? and :: to avoid ambiguity with the random operator.
fastspin has x := if condition then eval_if_true else eval_if_false. This means adding one keyword, "then", but I think it's easier to read than C's version.
3. Something better has to be done with strings. Although the utility of string(...) for comma-separated lists is indisputable, it is pretty wordy, especially for simple strings like "abcdef". It would be nice to come up with some sort of shorthand notation. Maybe let a simple "abc" return a pointer the way string does. But what to do about "a", which returns $61 now. Require a pseudo-function, like ord? Actually, ord would be handy for strings up to 4 bytes in length, since they can be packed into a long.
I agree, this is another place where Spin could be improved on. Many languages have different syntax for single characters than strings. SIngle quotes are taken, unfortunately, but maybe &x could mean "character x"? Or we could just require people to subscript, like "a"[0], but that's a bit of a pain.
4. "Lazy" Booleans (e.g. && ||). If the outcome of a Boolean expression is known before completion, quit evaluating the rest of it.
Oops, looks like I got this wrong -- I thought Spin AND and OR already worked this way! I think personally there's no harm in changing AND and OR to short-circuit evaluation for Spin2 -- the results are already the same except for side effects.
5. Variable-length argument lists. Allow stuff like
my_sum := sum(12, a, $56, x)
PUB sum(count, args[]) | i
repeat i from 0 to count - 1
result += args[i]
where count is implicitly assigned the value 4 in the above method call. This would come especially handy in formatting routines, where you have a format string à laprintf, followed by a list of values to print.
This seems like a nice idea, although I'd probably swap the order of the count and array (that way there's no ambiguity about whether count is a user parameter or not -- anything after an array parameter is something inserted by the compiler.
...Besides, after Microchip's native PIC mnemonics, anything else looks good!
-Phil
My favorite was "BTFSC", which meant "bit test file register and skip if clear". In our assembly language, we renamed that to "SB". For OR, I think they had "IORWF" which meant "inclusive-OR W with file register".
Comments
Here is the v16 instruction list. I already changed the bit operations to BITxx:
https://docs.google.com/spreadsheets/d/1J-CyOON6QUvB8lMIlAMlrru7dpWtL8XInvHiAxBwStI/edit?usp=sharing
Shouldn't TESTB have been included in the migration to BITxx , as (eg) BITRD, since it is the means to read BIT into CY/Z ?
It's not too late. Those BITxx instructions don't really pop like I wish they would. Maybe a '_' chr after BIT:
I don't know. Naming is one of the biggest difficulties in programming.
- also possible to improve 'pop' of that important suffix is
Besides, after Microchip's native PIC mnemonics, anything else looks good!
-Phil
i.e. why would you want to output a random bit?
Because Putin.
Let's see if the moderators notice that.
I agree.
My favorite was "BTFSC", which meant "bit test file register and skip if clear". In our assembly language, we renamed that to "SB". For OR, I think they had "IORWF" which meant "inclusive-OR W with file register".
BMH
COUT
We're not watching :-)
There also has to be a finite silicon cost to DRVRND & FLTRND ?
What would be needed for better open-drain support? You can always copy C or !C to a DIR bit via DIRC or DIRNC. Is there more needed?
Would that be BITFC, BITFNC or BITCF, BITNCF ?
I can see a use where the streamer is opendrain, which I think would need a pin-config for open drain (as many MCUs have now)
Maybe that is already there ?
BITxx are general register bit operations, while DIRxx/OUTxx/FLTxx/DRVxx are DIR and OUT bit operations whose index spans 64 bits (DIRA/DIRB and OUTA/OUTB). Just use those instructions, I think.
Oops yes, slight brain fade here, only paying half attention, and getting confused with 8051 opcodes, where the same BIT opcodes apply across all of Pin IO space and Flags and user RAM Boolean scratch bits.
No to ternary operators. That is just unnecessary source code obfuscation.
That an interesting point about variable length arguments lists using "args[]". We can add lots of Javascript features as well as C++ ones
Just say no to "_".
Didn't see a thing.
If you have inline assembly, there's no need for builtin Spin functions for PASM; instead you could create an object that has them all, and the function names would then be in the object namespace. E.g.: and then to use it do: You could even have the "instructions" object built in to the interpreter and/or always loaded with a predefined name like "instr".
This is exactly what fastspin does for most of the Spin builtins corresponding to instructions, except that it puts the function definitions into global namespace for compatibility with Spin.
Eric
Oneliners are good. In Perl we have, for example
fastspin has x := if condition then eval_if_true else eval_if_false. This means adding one keyword, "then", but I think it's easier to read than C's version.
I agree, this is another place where Spin could be improved on. Many languages have different syntax for single characters than strings. SIngle quotes are taken, unfortunately, but maybe &x could mean "character x"? Or we could just require people to subscript, like "a"[0], but that's a bit of a pain.
Oops, looks like I got this wrong -- I thought Spin AND and OR already worked this way! I think personally there's no harm in changing AND and OR to short-circuit evaluation for Spin2 -- the results are already the same except for side effects.
This seems like a nice idea, although I'd probably swap the order of the count and array (that way there's no ambiguity about whether count is a user parameter or not -- anything after an array parameter is something inserted by the compiler.
Eric
*=postedit
My favourite was BANDCF = Branch and catch fire !
ALELUYA !
Remember, the is no Moderation in P2 forums.
Is it no moderation forever or only until P2 goes on sale.
That's up to Ken and Chip.