I just posted v34i which has improved constant-expression resolving and internally simplified bitfield setups.
For the last few days, I've thought about the bitfield issue and I think what I had was just right. ADDPINS and ADDBITS are operators which work for both compile-time and run-time expressions and provide the most succinct functions that stay closest to the hardware and execute the fastest.
I thought a lot about bit ranges [top..bottom], but it would take a bunch more interpreter longs to support, plus we'd need more operator names, like [63 downtopin 56] and [23 downtobit 16].
I could yet add some constant-only PINHIGH[63..56] range allowances for pin and bitfield instructions, but those would only work in-situ. The nice thing about named operators is that they are commutable among CON, VAR, and code usage, whereas [63..56] is contextual in operation, either pin-metric or bit-metric. So, these look nice, but can only be written into certain points in your code and cannot be defined elsewhere. As it is now, you can do "CON pwm_pins = 32 addpins 7" for eight pins in a row. Then, you can do PINSTART(pwm_pins,mode,x,y) and use pwm_pins all over. I think it's best to stick with these two operators and keep things simpler in the bigger picture. There's just one concept to get and you're on your way.
Windows Defender does not like PNut_v34i. Automatically deleted when un Ziping the file. (Windows 7 Pro). Even Windows 10 complained, but let me keep it after scanning.
Chip, I think you are over thinking the x..y notation. Why would adding that require more keywords for the downto* stuff?
Like literally all you need to do is allow x..y to be interpreted as x addbits (y-x), and just error out it y-x is negative. Also why the heck is there addpins and addbits? don't they ultimately do the exact same thing?
With all the differences, you haven't made Spin2, you've made "new language for P2, that's not Spin". I expected Spin2 to have differences in the area P1 specific keywords, and for it to have additions for P2 specifics and new features, but for the basic language syntax I expected Spin2 to be a superset of Spin1. Oh well...
Chip, I think you are over thinking the x..y notation. Why would adding that require more keywords for the downto* stuff?
Like literally all you need to do is allow x..y to be interpreted as x addbits (y-x), and just error out it y-x is negative. Also why the heck is there addpins and addbits? don't they ultimately do the exact same thing?
With all the differences, you haven't made Spin2, you've made "new language for P2, that's not Spin". I expected Spin2 to have differences in the area P1 specific keywords, and for it to have additions for P2 specifics and new features, but for the basic language syntax I expected Spin2 to be a superset of Spin1. Oh well...
I think what we're finding is that Spin is more like BASIC than C/C++. It is a family of languages that bear a certain resemblance but are not necessarily compatible with each other.
Chip, I think you are over thinking the x..y notation. Why would adding that require more keywords for the downto* stuff?
Like literally all you need to do is allow x..y to be interpreted as x addbits (y-x), and just error out it y-x is negative. Also why the heck is there addpins and addbits? don't they ultimately do the exact same thing?
With all the differences, you haven't made Spin2, you've made "new language for P2, that's not Spin". I expected Spin2 to have differences in the area P1 specific keywords, and for it to have additions for P2 specifics and new features, but for the basic language syntax I expected Spin2 to be a superset of Spin1. Oh well...
I think what we're finding is that Spin is more like BASIC than C/C++. It is a family of languages that bear a certain resemblance but are not necessarily compatible with each other.
It's not like C(++) doesn't have it's fair share of compiler/platform-specific nonsense. Have you ever seen some C code for 16bit x86 DOS? lots of far* everywhere, hah,
Chip, I think you are over thinking the x..y notation. Why would adding that require more keywords for the downto* stuff?
Like literally all you need to do is allow x..y to be interpreted as x addbits (y-x), and just error out it y-x is negative. Also why the heck is there addpins and addbits? don't they ultimately do the exact same thing?
With all the differences, you haven't made Spin2, you've made "new language for P2, that's not Spin". I expected Spin2 to have differences in the area P1 specific keywords, and for it to have additions for P2 specifics and new features, but for the basic language syntax I expected Spin2 to be a superset of Spin1. Oh well...
They cannot be the same. We now have bit-addressing for all variables. That, alone, forces a syntax change. We'd have to get rid of a lot of language features to go back to Spin 1 compatibility.
I have been trying to explain that while we can use [top..bottom] notation, it is not portable outside of where it is typed, as it is contextual. I think it would be better to get people to use the new universal approach, rather than encourage them to put hard-coded bitfields into their code. You see ADDPINS/ADDBITS resolves to a single value which can be assigned to a constant symbol, written to a variable, and passed and applied all over your code without having to type anything over again in each instance.
I think it's important to remember that programming languages are for humans.
This...
somevalue := anothervalue[15..0]
is far more sensible to humans (especially those of use actually deploying the Propeller every day) than...
somevalue := anothervalue[0 addbits 15]
For example, I'm working on a sensor that returns a 32-bit frame as a group of bit fields, and the docs provide the starting and ending bits of each field. To translate that directly to the code is a benefit.
opcode := frame[31..26]
status := frame[25..24]
value := frame[23..08]
crc := frame[07..00]
To the point, the Propeller is already a bit arcane vis-a-vis the rest of the world; making the language even more arcane does nothing to invite new programmers in.
I wasn't saying to take away the new syntax, just have the old syntax be valid for the subset of cases that match Spin1's usage. Yes it would mean two ways to do things, but Spin/PASM are full of multiple ways to do the same things...
You seem to have decided that it's one or that other, and because the x..y notation would require more compiler work to cover all the cases and you think it would require interpreter changes (it absolutely should not) you don't want to do it.
Also, the notation for variables didn't have to change, it just needed more compiler side work to sort things out. The end result byte code would be the same as what you have now.
I wish the compiler was written in C/C++ instead of x86, because it would be a lot easier for many of us here to help make it do everything you wanted and also keep more Spin1 compatibility. It took me many many months to grock and convert all the Spin1 x86 into C/C++, and then alot more to make it actually work exactly right in all cases. I just can't do that (and much more for this new one) again. Hopefully you are willing to share the x86 with more people this time so others can do it.
I wish the compiler was written in C/C++ instead of x86, because it would be a lot easier for many of us here to help make it do everything you wanted and also keep more Spin1 compatibility.
There is a Spin compiler that is written in C++. It's called FastSpin. That could be made into a Chip-style Spin2 compiler that others could contribute to. For that matter, there is your own OpenSpin that is written in C++.
Chip,
I think you are stuck thinking about it all from the bottom up instead of the top down. You see how the hardware does it and want to make Spin match that, but the whole point of a high level language compiler is to abstract the hardware into something more human friendly.
You spend the time on the compiler to make it produce good results for the hardware, you don't make every programmer spend the time figuring out the the oddball notation just to save compiler work.
Others re: C/C++ having differences,
The basic language syntax is standard for C and for C++, it's the libraries and extensions that add to the base language that vary. Also, newer standards are supersets of the older ones.
There are trillions of lines of C/C++ code out there that rely on this.
BTW... if the issue is variables in the [start..end] values (which do work in Spin1 for outa, ina, dira), I would be okay with giving them up -- when I use that syntax it is nearly exclusively with constants. If the Spin2 compiler convert the [start..end] syntax with constants to a bitfield value, that would be great. Again, for me it's about readability.
I think it's important to remember that programming languages are for humans.
This...
somevalue := anothervalue[15..0]
is far more sensible to humans (especially those of use actually deploying the Propeller every day) than...
somevalue := anothervalue[0 addbits 15]
For example, I'm working on a sensor that returns a 32-bit frame as a group of bit fields, and the docs provide the starting and ending bits of each field. To translate that directly to the code is a benefit.
opcode := frame[31..26]
status := frame[25..24]
value := frame[23..08]
crc := frame[07..00]
To the point, the Propeller is already a bit arcane vis-a-vis the rest of the world; making the language even more arcane does nothing to invite new programmers in.
Okay. Doing that with constant values is pretty straightforward. If I have to accommodate variables, the complexity explodes. Would you be satisfied if such [top..bottom] usages were limited to constants?
I wish the compiler was written in C/C++ instead of x86, because it would be a lot easier for many of us here to help make it do everything you wanted and also keep more Spin1 compatibility.
There is a Spin compiler that is written in C++. It's called FastSpin. That could be made into a Chip-style Spin2 compiler that others could contribute to. For that matter, there is your own OpenSpin that is written in C++.
OpenSpin would require largely a complete rewrite to deal with all the changes Chip has done for Spin2, it's too closely matching his old x86 code (which is now vastly different from the new one). Also, almost no one uses it, and Parallax didn't actually make it the standard one in PropTool/etc. FastSpin is in a better place for sure as far as making it handle Spin2, but we need Parallax to get behind it as an official compiler for P2 (and P1).
In any case, if the official parallax Spin2 compiler doesn't exactly match the feature set of FastSpin or OpenSpin (if it gets updated) then it creates a lot of hassle for users because shared code won't compile on all Spin2 compilers.
This was already an issue for P1 users, because most people just used PropTool, and shared code from BST/etc. would often fail for people using PropTool.
I just looked through the source code of a fairly large, recent project of mine.
There are no occurrences of [x..y] anywhere...
Not in main code, FullDuplexSerial, Numbers, FSRW, safe_spi, EVE2 display driver, or my I2C driver.
Thinking more about this, I think it was quite rare that I used this...
Anyway, although it would be nice, I wonder how big an issue this actually is...
If I have to accommodate variables, the complexity explodes. Would you be satisfied if such [top..bottom] usages were limited to constants?
To me, having variables in the [start..end] values is nice to have, but not have to have -- I would be fine with constants for code readability.
Thanks, Chip!
Anyway, although it would be nice, I wonder how big an issue this actually is...
@Rayman: Given this syntax now extends to all variables, I will use this a lot. I do now in Spin1 with IO, probably because I design my circuits to take advantage of the syntax. I especially like that I can reverse the bits in the [start..end] group -- this has made PCB layout much nicer in many cases.
I think it's important to remember that programming languages are for humans.
This...
somevalue := anothervalue[15..0]
is far more sensible to humans (especially those of use actually deploying the Propeller every day) than...
somevalue := anothervalue[0 addbits 15]
For example, I'm working on a sensor that returns a 32-bit frame as a group of bit fields, and the docs provide the starting and ending bits of each field. To translate that directly to the code is a benefit.
opcode := frame[31..26]
status := frame[25..24]
value := frame[23..08]
crc := frame[07..00]
To the point, the Propeller is already a bit arcane vis-a-vis the rest of the world; making the language even more arcane does nothing to invite new programmers in.
Okay. Doing that with constant values is pretty straightforward. If I have to accommodate variables, the complexity explodes. Would you be satisfied if such [top..bottom] usages were limited to constants?
A high level language is just that. If we cannot easily make spin1 and spin2 co-exist, then you've lost all the spin1 code out there. That will mean it will be another 5+ years before we get anywhere near the p1 code that's there now. Remember, it took years to get decent libraries for P1.
If I cannot easily convert SPIN1 to SPIN2 then you've lost me!
IMHO if spin1 is not closely upward compatible with spin2, then you are confirming to all those who are against spin, that it is truly a one-off language, with all the negative connotation that goes with it.
If it's not even compatible between processors from the same company, you've lost any reason for anyone to learn it.
Windows Defender does not like PNut_v34i. Automatically deleted when un Ziping the file. (Windows 7 Pro). Even Windows 10 complained, but let me keep it after scanning.
I had a similar experience with AVG Anti virus (Win7Pro) complaining and quarantined PNut until it had scan it offline.
IMHO if spin1 is not closely upward compatible with spin2, then you are confirming to all those who are against spin, that it is truly a one-off language, with all the negative connotation that goes with it.
If it's not even compatible between processors from the same company, you've lost any reason for anyone to learn it.
There are so many new things that the language has to do that it is impossible to make it compatible with the original.
I guess this is the downside of a language so closely aligned to the underlying hardware. At least we have two C options at launch for those who would prefer to use a more processor-agnostic language.
The Spin language shouldn't have had any hardware specifics in it, that should have all been in libraries/extensions that get included with the compiler.
All Spin needed was the ability to do inline PASM, and that would have made it so that the base language + libraries/extensions would have felt just like Spin does.
Anyway, I've given up (really this time) on trying to change Chip's mind on this Spin2 stuff, he doesn't appear to be listening, and really it doesn't matter in the long run. I'll be using FlexC for now (and maybe indefinitely), and I'll be trying to help Eric improve it.
I just hope Ken sticks to the idea that P2 can't launch with a closed source compiler and IDE that are Windows/x86 only (and by x86 I mean TASM (30+ years old) targeting a 386 (35+ years old), modern C/C++ compilers target even 10 year old CPUs (not just x86) will run circles around 386 asm (yes even hand written 386)). Ken doesn't have much time to get Parallax backing/supporting the solutions that most of his customers and potential customers want for P2.
Comments
For the last few days, I've thought about the bitfield issue and I think what I had was just right. ADDPINS and ADDBITS are operators which work for both compile-time and run-time expressions and provide the most succinct functions that stay closest to the hardware and execute the fastest.
I thought a lot about bit ranges [top..bottom], but it would take a bunch more interpreter longs to support, plus we'd need more operator names, like [63 downtopin 56] and [23 downtobit 16].
I could yet add some constant-only PINHIGH[63..56] range allowances for pin and bitfield instructions, but those would only work in-situ. The nice thing about named operators is that they are commutable among CON, VAR, and code usage, whereas [63..56] is contextual in operation, either pin-metric or bit-metric. So, these look nice, but can only be written into certain points in your code and cannot be defined elsewhere. As it is now, you can do "CON pwm_pins = 32 addpins 7" for eight pins in a row. Then, you can do PINSTART(pwm_pins,mode,x,y) and use pwm_pins all over. I think it's best to stick with these two operators and keep things simpler in the bigger picture. There's just one concept to get and you're on your way.
So, while this may work as expected:
This one probably won't, right?
It might be useful if it could generate error messages...
Like literally all you need to do is allow x..y to be interpreted as x addbits (y-x), and just error out it y-x is negative. Also why the heck is there addpins and addbits? don't they ultimately do the exact same thing?
With all the differences, you haven't made Spin2, you've made "new language for P2, that's not Spin". I expected Spin2 to have differences in the area P1 specific keywords, and for it to have additions for P2 specifics and new features, but for the basic language syntax I expected Spin2 to be a superset of Spin1. Oh well...
x ADDPINS y 'computes (x & $3F) + (y & $1F) << 6
x ADDBITS y 'computes (x & $1F) + (y & $1F) << 5
They must be different this way to work with pin instructions versus bit instructions at the PASM level.
They cannot be the same. We now have bit-addressing for all variables. That, alone, forces a syntax change. We'd have to get rid of a lot of language features to go back to Spin 1 compatibility.
I have been trying to explain that while we can use [top..bottom] notation, it is not portable outside of where it is typed, as it is contextual. I think it would be better to get people to use the new universal approach, rather than encourage them to put hard-coded bitfields into their code. You see ADDPINS/ADDBITS resolves to a single value which can be assigned to a constant symbol, written to a variable, and passed and applied all over your code without having to type anything over again in each instance.
This... is far more sensible to humans (especially those of use actually deploying the Propeller every day) than... For example, I'm working on a sensor that returns a 32-bit frame as a group of bit fields, and the docs provide the starting and ending bits of each field. To translate that directly to the code is a benefit. To the point, the Propeller is already a bit arcane vis-a-vis the rest of the world; making the language even more arcane does nothing to invite new programmers in.
You seem to have decided that it's one or that other, and because the x..y notation would require more compiler work to cover all the cases and you think it would require interpreter changes (it absolutely should not) you don't want to do it.
Also, the notation for variables didn't have to change, it just needed more compiler side work to sort things out. The end result byte code would be the same as what you have now.
I wish the compiler was written in C/C++ instead of x86, because it would be a lot easier for many of us here to help make it do everything you wanted and also keep more Spin1 compatibility. It took me many many months to grock and convert all the Spin1 x86 into C/C++, and then alot more to make it actually work exactly right in all cases. I just can't do that (and much more for this new one) again. Hopefully you are willing to share the x86 with more people this time so others can do it.
I think you are stuck thinking about it all from the bottom up instead of the top down. You see how the hardware does it and want to make Spin match that, but the whole point of a high level language compiler is to abstract the hardware into something more human friendly.
You spend the time on the compiler to make it produce good results for the hardware, you don't make every programmer spend the time figuring out the the oddball notation just to save compiler work.
Others re: C/C++ having differences,
The basic language syntax is standard for C and for C++, it's the libraries and extensions that add to the base language that vary. Also, newer standards are supersets of the older ones.
There are trillions of lines of C/C++ code out there that rely on this.
Okay. Doing that with constant values is pretty straightforward. If I have to accommodate variables, the complexity explodes. Would you be satisfied if such [top..bottom] usages were limited to constants?
OpenSpin would require largely a complete rewrite to deal with all the changes Chip has done for Spin2, it's too closely matching his old x86 code (which is now vastly different from the new one). Also, almost no one uses it, and Parallax didn't actually make it the standard one in PropTool/etc. FastSpin is in a better place for sure as far as making it handle Spin2, but we need Parallax to get behind it as an official compiler for P2 (and P1).
In any case, if the official parallax Spin2 compiler doesn't exactly match the feature set of FastSpin or OpenSpin (if it gets updated) then it creates a lot of hassle for users because shared code won't compile on all Spin2 compilers.
This was already an issue for P1 users, because most people just used PropTool, and shared code from BST/etc. would often fail for people using PropTool.
There are no occurrences of [x..y] anywhere...
Not in main code, FullDuplexSerial, Numbers, FSRW, safe_spi, EVE2 display driver, or my I2C driver.
Thinking more about this, I think it was quite rare that I used this...
Anyway, although it would be nice, I wonder how big an issue this actually is...
Thanks, Chip!
@Rayman: Given this syntax now extends to all variables, I will use this a lot. I do now in Spin1 with IO, probably because I design my circuits to take advantage of the syntax. I especially like that I can reverse the bits in the [start..end] group -- this has made PCB layout much nicer in many cases.
A high level language is just that. If we cannot easily make spin1 and spin2 co-exist, then you've lost all the spin1 code out there. That will mean it will be another 5+ years before we get anywhere near the p1 code that's there now. Remember, it took years to get decent libraries for P1.
If I cannot easily convert SPIN1 to SPIN2 then you've lost me!
If it's not even compatible between processors from the same company, you've lost any reason for anyone to learn it.
Just sayin...
I had a similar experience with AVG Anti virus (Win7Pro) complaining and quarantined PNut until it had scan it offline.
Tony
Exactly.
All Spin needed was the ability to do inline PASM, and that would have made it so that the base language + libraries/extensions would have felt just like Spin does.
Anyway, I've given up (really this time) on trying to change Chip's mind on this Spin2 stuff, he doesn't appear to be listening, and really it doesn't matter in the long run. I'll be using FlexC for now (and maybe indefinitely), and I'll be trying to help Eric improve it.
I just hope Ken sticks to the idea that P2 can't launch with a closed source compiler and IDE that are Windows/x86 only (and by x86 I mean TASM (30+ years old) targeting a 386 (35+ years old), modern C/C++ compilers target even 10 year old CPUs (not just x86) will run circles around 386 asm (yes even hand written 386)). Ken doesn't have much time to get Parallax backing/supporting the solutions that most of his customers and potential customers want for P2.