If it doesn't happen now, it won't happen later. There will always be something new and interesting to deal with. Better to complete the job. There are a lot of use who code the P1 that know there will be some conversion work moving to the P2, but those issues should be mitigated as much as possible, especially since Spin1 is so clean and elegant.
Chip,
He told Cluso to shut up. Cluso deserves more respect than that.
Re: Spin2, I've already said basically the same thing several times, and you either didn't understand it or just don't want to do the compiler work (which is all it is). I know part of why you are hung up on this, it's because of how the compiler parses the code, and getting it to be properly context aware (which is what's needed to resolve the bitfield syntax issue) is a huge pain in 386 asm. It's even more of a pain because it's parse to build the symbol table, then parse and encode as you go, instead of the more typical parse into an AST then do everything from the AST, like build the symbol table, determine context, and then encode using all that built up stuff. Anyway, you do need to get Spin2 done, and at this point you should probably just make it what you think is best, because you don't have time to listen to us here anymore. Things will work out eventually.
It's not the parsing, actually. I know how to do that. I'm just resource constrained, at this point. I only have one free main bytecode and I need to sort out how to best do this. I intend to allow variables in '.[top..bottom]', too, as well as constants. With constants, there's no need for any special bytecode, as I can just compute the bitfield constant and it's done. With variables, I think the best way to do it is take the 'top' and 'bottom' values on the stack and change them to 'bottom' and 'top-bottom', respectively. I can do that with one bytecode. Then, I can execute the ADDBITS or ADDPINS bytecode to get the actual bitfield or pinfield value. That is how I will handle this. So, pinfields and bitfields can be expressed with top and bottom numbers, in addition to bottom and additional-bits.
It doesn't need a byte code though? Why would it? You already have the byte codes to do it your way, so the compiler should be able to parse either syntax into the same end result byte codes.
The fact that you say it needs a new byte code confirms what I've said before, you are thinking about it from the wrong perspective. It is a compiler/parsing issue.
It doesn't need a byte code though? Why would it? You already have the byte codes to do it your way, so the compiler should be able to parse either syntax into the same end result byte codes.
The fact that you say it needs a new byte code confirms what I've said before, you are thinking about it from the wrong perspective. It is a compiler/parsing issue.
Well, straighten me out, then...
If we have 'topbit' and 'bottombit' and we need ((topbit-bottombit & $1F) << 5 | (bottombit & $1F)), how do we efficiently get there?
EDIT: 'topbit' and 'bottombit' are each expressions containing variables or methods, so they cannot be computed at compile time.
Okay, I get it now, it's the variables variant that can't be the "exact same end results byte codes" it does require doing the math in front of the normal addpins/addbits byte codes.
For literal numbers it's trivial because the math can be done at compile time, but with variables you need to do the math on the fly. You are wanting the new bytecode to do the math/etc. all in one to make it a tiny bit more efficient.
Just use the normal math byte codes before the addpins/addbits byte codes when variables are involved and they used the top..bot syntax. That's plenty efficient enough for this...
I can't imagine people using this with variables instead of literal numbers very much at all, and if they do and really need the efficiency in their programs they can use the new syntax instead of the old one.
I'm sorry that I wasn't more explicit before and didn't ask the right questions to understand your apprehension.
Okay, I get it now, it's the variables variant that can't be the "exact same end results byte codes" it does require doing the math in front of the normal addpins/addbits byte codes.
For literal numbers it's trivial because the math can be done at compile time, but with variables you need to do the math on the fly. You are wanting the new bytecode to do the math/etc. all in one to make it a tiny bit more efficient.
Just use the normal math byte codes before the addpins/addbits byte codes when variables are involved and they used the top..bot syntax. That's plenty efficient enough for this...
I can't imagine people using this with variables instead of literal numbers very much at all, and if they do and really need the efficiency in their programs they can use the new syntax instead of the old one.
I'm sorry that I wasn't more explicit before and didn't ask the right questions to understand your apprehension.
I found a way to do it with one additional instruction in the interpreter. I just happened to have freed a long the other day in the interpreter and I had a single bytecode available. See the 'e' sequence:
'
'
' Ternary (y ? z : x) (12 longs)
' ROTXY(x,y,t)
' POLXY(r,t)
' XYPOL(x,y)
' Bitrange (top,bottom --> bottom,top-bottom)
'
'
rotxy_ setq #2-1 'a b a: ternary (y ? z : x)
rdlong y,--ptra 'a b b: ROTXY(x,y,t)
_ret_ tjnz y,#.true 'a | c: POLXY(r,t)
.true _ret_ mov x,z 'a | d: XYPOL(x,y)
polxy_ popa y ' | c d e e: bitrange (top,bottom --> bottom,top-bottom)
setq z ' b | | |
qrotate y,x ' b c | |
qvector y,x ' | | d |
getqx x ' b c d |
pusha x ' b c d e
_ret_ getqy x ' b c d |
_ret_ subr x,y ' e
So, the 'top' and 'bottom' expressions get compiled and solve onto the stack at runtime. Then this 'bitrange' bytecode does the reordering and subtraction, preparing the stack data for both the ADDPINS and ADDBITS bytecode which performs the specific mask-shift-OR operation for either the pinfield or bitfield.
Now, I just need to get the compiler doing its part.
I'm a little amazed how this thread is running. Now we are running for a final P2. It's not about politics, its about possibilities. Whenever hardware is available we can start to make products in masses. What is already in the going in different places. A single high flyer product may be sufficient. The rest should be fun. Chip brought us the P1 and initiated the P2, which could not come to reality without the help of all the community. Those that made contributions, tested what exists or just applauded, even watched. We have to know: the world is a place of manifolds. That guarantees the ability to evolve and to survive. That's true for men and languages, including computer nerds and computer languages. To find simple solutions is the ultimate goal: (42) but to simplify real complexity just to win the next day is the original sin. That will lead to an complete desaster. So please: calm down. Let Chip finish his work and find some recreational time, create succesfull products programmed in any language with any tool and lets all together start over then to have the next, even better P. A P that will always know: my success is based on the success of the predecessor and that not inherited a total mess.
? Customers can program P2 now.
Customers wanting to write programs for P2, will expect a language they are familiar with, or very easy porting from a language they are familiar with.
(...)
Existing right now are language users are familiar with :
fastspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler
but missing is a decent GUI debugger.
If you want rapid customer ramp, it would have been smarter to have Chip work on a good debugger so that all those languages users are familiar with, can SingleStep/Break/Watch - which other vendors offer.
It seems to me you should be able to move the P1 spin interpreter over to the P2 and emulate a P1 on the P2. You have pins 30 and 31 for serial, you have 28 and 29 for flash memory.
One could use a Prop plug and load there spin program unchanged into the P1 emulator and it would run unmodified.
[The angst around here in the last few days has been very high. A year ago, many of you were enthusiastic about discussing Spin2 features. Now, it's practically a hot-button issue. It's Spin1 compatibility or death! Or, it should be Python and/or C++, but not Spin, at all. There's no winning around here, lately.
I'm going to keep working on Spin2 because that's what I think the best course of action is. I have a really good feeling about it and I'm looking forward to getting it documented and writing code with it. I just need to see about this top..bottom stuff, first.
I'm sorry if I've contributed to this angst. I think everyone just wants P2 to be a success and have various ideas about what tools might make that more likely. I think it is very likely that most people will eventually adopt the tool that is sanctioned by Parallax and I'm afraid the hard work others have done to produce alternate toolchains will fall by the wayside. That is especially concerning when two of those efforts have produced C compilers that might actually attract more potential customers than the official Spin2 compiler that will be promoted by Parallax. I guess the good part of all of this angst is that it is in service of trying to help P2 succeed.
[The angst around here in the last few days has been very high. A year ago, many of you were enthusiastic about discussing Spin2 features. Now, it's practically a hot-button issue. It's Spin1 compatibility or death! Or, it should be Python and/or C++, but not Spin, at all. There's no winning around here, lately.
I'm going to keep working on Spin2 because that's what I think the best course of action is. I have a really good feeling about it and I'm looking forward to getting it documented and writing code with it. I just need to see about this top..bottom stuff, first.
I'm sorry if I've contributed to this angst. I think everyone just wants P2 to be a success and have various ideas about what tools might make that more likely. I think it is very likely that most people will eventually adopt the tool that is sanctioned by Parallax and I'm afraid the hard work others have done to produce alternate toolchains will fall by the wayside. That is especially concerning when two of those efforts have produced C compilers that might actually attract more potential customers than the official Spin2 compiler that will be promoted by Parallax. I guess the good part of all of this angst is that it is in service of trying to help P2 succeed.
It all makes Spin2 better. I've just about got all the [top..bottom] stuff worked out for pins and bits, with variables, and it didn't even grow the interpreter. The interpreter footprint is at exactly $1000 bytes (4KB).
I hope the C compilers others have made will be very useful to people. If they can all compile the same source code, that will be a good thing. It should give P2 users confidence.
I found a way to do it with one additional instruction in the interpreter. I just happened to have freed a long the other day in the interpreter and I had a single bytecode available. See the 'e' sequence:
Nice work @cgracey. Very neat and tidy to fit it in!
Will this "Bitrange" byte code be directly exposed as an operator or other named function directly from the SPIN2 language, or is it mostly used internally for the pin spanning and bit spanning operations? I wonder if it should have an official name to it or if you plan to use the ".." operator syntax? It's sort of computing a displacement between two one dimensional co-ordinates isn't it? Perhaps this would be allowed by the language.
(base, offset) := b..a ' compute base and offset for a span from b to a
I found a way to do it with one additional instruction in the interpreter. I just happened to have freed a long the other day in the interpreter and I had a single bytecode available. See the 'e' sequence:
Nice work @cgracey. Very neat and tidy to fit it in!
Will this "Bitrange" byte code be directly exposed as an operator or other named function directly from the SPIN2 language, or is it mostly used internally for the pin spanning and bit spanning operations? I wonder if it should have an official name to it or if you plan to use the ".." operator syntax? It's sort of computing a displacement between two one dimensional co-ordinates isn't it? Perhaps this would be allowed by the language.
(base, offset) := b..a ' compute base and offset for a span from b to a
Well, it's just a preparatory bytecode before the ADDPINS or ADDBITS bytecode. I'm really glad it occurred to me that this could be done, because it solves the problem of having to get specific about ADDPINS or ADDBITS. Discrete solutions would have taken at least one more bytecode, or more if assignments were allowed.
I don't know if there's a lot of value in exposing it, because it really needs to be used with ADDPINS or ADDBITS. Generating two discrete values for later use seems burdensome on the programmer. Better to get all the way down to business. The 'top..bottom' result is contextual for either pins or bits and so needs different handling in the compiler based on whether it's targeting pins or bits. Otherwise, some more complicated syntax would be needed beyond the clean 'top..bottom'.
My plan now is to just support the 'top..bottom' syntax where a pinfield or bitfield is being expressed, and the compiler will know which one, of course. If you want to specify a pinfield or bitfield as a constant for use in code, you'll need to use the ADDPINS/ADDBITS operators.
I just posted v34j with the following improvements:
1) PINHIGH(top..bottom) '..' syntax added for pinfields.
2) AnyVariable.[top..bottom] '..' syntax added for bitfields.
3) '-c' added as a command-line option to compile without downloading.
The 'top..bottom' syntax works with both constants and variables for top and bottom.
There's only ONE more thing I'd like to do with the compiler, for now.
I want to make it so that only desired constants get published into the .obj file. Right now, all CONstants get published and that's messy. We either need a new CON-like word or some notation to say that a CON block is to be published into the .obj. This is really simple to do, but I'm not sure which syntax would be best.
How about having a new block name "VAL" for values, which is like a private CON? Jeff thought of this at Parallax. Or, we could put the word "public" after CON, to publish all that CON block's values. Any better ideas?
Maybe I don't understand something here, but wouldn't the compiler just ignore CONstants that are not used in the code, and include those that are ? (optimization).
If there is a case for the user pushing values, then I think keeping CON and adding a suffix like "public" would be simpler to explain/document, rather than introducing another keyword.
The constants should be nicely listable in the .doc file. Having to show every constant is just a big mess, as only a handful are probably intended for the parent object.
There's only ONE more thing I'd like to do with the compiler, for now.
I want to make it so that only desired constants get published into the .obj file. Right now, all CONstants get published and that's messy. We either need a new CON-like word or some notation to say that a CON block is to be published into the .obj. This is really simple to do, but I'm not sure which syntax would be best.
How about having a new block name "VAL" for values, which is like a private CON? Jeff thought of this at Parallax. Or, we could put the word "public" after CON, to publish all that CON block's values. Any better ideas?
That's all sounding a bit hidden.
If you are bothered by larger files, why not just include those items that are actually used ?
If you are talking about linking, other compilers use public and extern to control what is carried across linkable files.
Assemblers also have $LIST and $NOLIST to give user control of what goes into .LST files.
A .doc file is produced which contains all methods and constants for the object. That thing should not have unnecessary constants in it, because it just makes for a huge mess. Only the constants that are intended to be used by the parent should be shown. So, it only has to do with file size in terms of what someone has to look at visually.
@cgracey Is there an updated document with command-line switches for PNut?
pnut 'just start app
pnut spinfile 'load spinfile (don't type .spin2, as it's assumed)
pnut spinfile -c 'compile spinfile, then exit
pnut spinfile -r 'compile and run spinfile, then exit
pnut spinfile -f 'compile and flash spinfile, then exit
Comments
It's not the parsing, actually. I know how to do that. I'm just resource constrained, at this point. I only have one free main bytecode and I need to sort out how to best do this. I intend to allow variables in '.[top..bottom]', too, as well as constants. With constants, there's no need for any special bytecode, as I can just compute the bitfield constant and it's done. With variables, I think the best way to do it is take the 'top' and 'bottom' values on the stack and change them to 'bottom' and 'top-bottom', respectively. I can do that with one bytecode. Then, I can execute the ADDBITS or ADDPINS bytecode to get the actual bitfield or pinfield value. That is how I will handle this. So, pinfields and bitfields can be expressed with top and bottom numbers, in addition to bottom and additional-bits.
The fact that you say it needs a new byte code confirms what I've said before, you are thinking about it from the wrong perspective. It is a compiler/parsing issue.
Well, straighten me out, then...
If we have 'topbit' and 'bottombit' and we need ((topbit-bottombit & $1F) << 5 | (bottombit & $1F)), how do we efficiently get there?
EDIT: 'topbit' and 'bottombit' are each expressions containing variables or methods, so they cannot be computed at compile time.
For literal numbers it's trivial because the math can be done at compile time, but with variables you need to do the math on the fly. You are wanting the new bytecode to do the math/etc. all in one to make it a tiny bit more efficient.
Just use the normal math byte codes before the addpins/addbits byte codes when variables are involved and they used the top..bot syntax. That's plenty efficient enough for this...
I can't imagine people using this with variables instead of literal numbers very much at all, and if they do and really need the efficiency in their programs they can use the new syntax instead of the old one.
I'm sorry that I wasn't more explicit before and didn't ask the right questions to understand your apprehension.
I found a way to do it with one additional instruction in the interpreter. I just happened to have freed a long the other day in the interpreter and I had a single bytecode available. See the 'e' sequence:
So, the 'top' and 'bottom' expressions get compiled and solve onto the stack at runtime. Then this 'bitrange' bytecode does the reordering and subtraction, preparing the stack data for both the ADDPINS and ADDBITS bytecode which performs the specific mask-shift-OR operation for either the pinfield or bitfield.
Now, I just need to get the compiler doing its part.
Exactly!
One could use a Prop plug and load there spin program unchanged into the P1 emulator and it would run unmodified.
Mike
It all makes Spin2 better. I've just about got all the [top..bottom] stuff worked out for pins and bits, with variables, and it didn't even grow the interpreter. The interpreter footprint is at exactly $1000 bytes (4KB).
I hope the C compilers others have made will be very useful to people. If they can all compile the same source code, that will be a good thing. It should give P2 users confidence.
Nice work @cgracey. Very neat and tidy to fit it in!
Will this "Bitrange" byte code be directly exposed as an operator or other named function directly from the SPIN2 language, or is it mostly used internally for the pin spanning and bit spanning operations? I wonder if it should have an official name to it or if you plan to use the ".." operator syntax? It's sort of computing a displacement between two one dimensional co-ordinates isn't it? Perhaps this would be allowed by the language.
(base, offset) := b..a ' compute base and offset for a span from b to a
Well, it's just a preparatory bytecode before the ADDPINS or ADDBITS bytecode. I'm really glad it occurred to me that this could be done, because it solves the problem of having to get specific about ADDPINS or ADDBITS. Discrete solutions would have taken at least one more bytecode, or more if assignments were allowed.
I don't know if there's a lot of value in exposing it, because it really needs to be used with ADDPINS or ADDBITS. Generating two discrete values for later use seems burdensome on the programmer. Better to get all the way down to business. The 'top..bottom' result is contextual for either pins or bits and so needs different handling in the compiler based on whether it's targeting pins or bits. Otherwise, some more complicated syntax would be needed beyond the clean 'top..bottom'.
My plan now is to just support the 'top..bottom' syntax where a pinfield or bitfield is being expressed, and the compiler will know which one, of course. If you want to specify a pinfield or bitfield as a constant for use in code, you'll need to use the ADDPINS/ADDBITS operators.
This feels like a good outcome to me.
1) PINHIGH(top..bottom) '..' syntax added for pinfields.
2) AnyVariable.[top..bottom] '..' syntax added for bitfields.
3) '-c' added as a command-line option to compile without downloading.
The 'top..bottom' syntax works with both constants and variables for top and bottom.
https://drive.google.com/file/d/1YgIBjIfICTnLvDO_k0fPWcn7v_EzAUPw/view?usp=sharing
I guess it's not thinking we should give it some money today.
https://drive.google.com/uc?export=download&id=1YgIBjIfICTnLvDO_k0fPWcn7v_EzAUPw
I want to make it so that only desired constants get published into the .obj file. Right now, all CONstants get published and that's messy. We either need a new CON-like word or some notation to say that a CON block is to be published into the .obj. This is really simple to do, but I'm not sure which syntax would be best.
How about having a new block name "VAL" for values, which is like a private CON? Jeff thought of this at Parallax. Or, we could put the word "public" after CON, to publish all that CON block's values. Any better ideas?
If there is a case for the user pushing values, then I think keeping CON and adding a suffix like "public" would be simpler to explain/document, rather than introducing another keyword.
Maybe:
Parent#name
#name
.#name
Something like that?
That's all sounding a bit hidden.
If you are bothered by larger files, why not just include those items that are actually used ?
If you are talking about linking, other compilers use public and extern to control what is carried across linkable files.
Assemblers also have $LIST and $NOLIST to give user control of what goes into .LST files.