For SPIN, pointers to objects would be good. Would be nice to be able to fetch a SPIN object from storage of some kind and just run it easily. Of all the things SPIN V1 could have included, that one would have been sweet, IMHO.
P2 is more roomy. Seems to me strings in some official library would work just as well as adding them to the language formally would.
Obviously, provide for bigger memory.
I'm 50/50 on structures. Nice to have, but not strictly necessary IMHO. SPIN being really lean is one strong attribute. Would be a shame to lose it.
I would deffo put "in line" PASM in there this time, so that LMM type PASM can be input directly where needed. With all the new instructions, perhaps there is room in the COG for that kind of thing. I know language purists don't like that kind of thing, but I'm a big fan of inline assembly. It's a great, "just get it done" kind of facility that rocks hard when it's used. Then again, it makes things harder for others, but then again, it can not be used too. Better to have it in there, IMHO.
Beyond that, just a nice set of object libraries featuring the best of the best developed so far. If that's out there earlier, it will solidify users around those libraries and improving them more. Won't be perfect, but will likely be better now.
I think fixed point would be really cool to have in SPIN, though it can be in a library like float should be. I would not add floats to SPIN personally.
Stuff for the libraries:
SD
Floating Point
Serial
Strings
Graphics
SPI
External SRAM (If applicable at all --I don't know at this stage)
etc...
Instructions to deal with all the groovy new "smart I/O pin" stuff, similar to what SPIN does now. I'm torn on that one too, simply because it's going to thicken SPIN up, but then again, when it was done this way the first time, SPIN ended up being pretty accessible too. ???
What to do with the hardware threads? Ideas?
Oh, path-names being valid in OBJ specifications! Let's do that this time around.
Oh, path-names being valid in OBJ specifications! Let's do that this time around.
Yes, definitely, but relative paths only to preserve installation independence. The paths would be relative to an installation-dependent $PATH environment variable, IOW a list of absolute directory references that specifies the search order. The environment variable should be able to be prepended to by a program directive, however; but such directives should never be allowed in code meant for distribution.
This entails a burden on the OBEX overseer, to define and manage subcategories and to make sure that submitted objects get put in the right category.
Wow, this thread is doing what I hoped. Great ideas. I agree especially with pedward and phil. We want things tight and microcontroller like, but with 120k base ram, we can probably have some of the nice things that higher end 8-bit computers or 16 bit computers had. Cool.
Comments
P2 is more roomy. Seems to me strings in some official library would work just as well as adding them to the language formally would.
Obviously, provide for bigger memory.
I'm 50/50 on structures. Nice to have, but not strictly necessary IMHO. SPIN being really lean is one strong attribute. Would be a shame to lose it.
I would deffo put "in line" PASM in there this time, so that LMM type PASM can be input directly where needed. With all the new instructions, perhaps there is room in the COG for that kind of thing. I know language purists don't like that kind of thing, but I'm a big fan of inline assembly. It's a great, "just get it done" kind of facility that rocks hard when it's used. Then again, it makes things harder for others, but then again, it can not be used too. Better to have it in there, IMHO.
Beyond that, just a nice set of object libraries featuring the best of the best developed so far. If that's out there earlier, it will solidify users around those libraries and improving them more. Won't be perfect, but will likely be better now.
I think fixed point would be really cool to have in SPIN, though it can be in a library like float should be. I would not add floats to SPIN personally.
Stuff for the libraries:
SD
Floating Point
Serial
Strings
Graphics
SPI
External SRAM (If applicable at all --I don't know at this stage)
etc...
Instructions to deal with all the groovy new "smart I/O pin" stuff, similar to what SPIN does now. I'm torn on that one too, simply because it's going to thicken SPIN up, but then again, when it was done this way the first time, SPIN ended up being pretty accessible too. ???
What to do with the hardware threads? Ideas?
Oh, path-names being valid in OBJ specifications! Let's do that this time around.
This entails a burden on the OBEX overseer, to define and manage subcategories and to make sure that submitted objects get put in the right category.
-Phil