Method pointers have been mentioned as a new feature for Spin2 but I'd also like to make a request for object references. Even if we never have inheritance, object references would allow delegation which would achieve many of the same goals. Of course, any of this requires a stronger concept of types which may move Spin to much in the direction of C++.
Interesting. Surely method pointers is not what we want. If you have a pointer/reference to a method how do you know which instance it applies to when you call it.
What we need pointers/references to objects. With that a method call is just a dot away, "someObjectInstance.someMethod(param, ...)"
I worry about the cry for types in Spin. We could end up with types for byte, word, long, float, object, structure,... It's going to add complexity to the language. At some point it becomes a nightmare like C++.
I'm not convinced that being able to call C from Spin or vice versa is necessary. Can't we just arrange to run C/C++ in a COG and have it exchange messages with Spin running in another COG?
Speaking of messages. What about having some kind of message exchange channel/mail box system baked into the language itself. Such a standard would make interoperating with other languages easier. This has been a bit of a stumbling block in the P1. Recycling Spin objects that are mostly PASM for use from C was troublesome.
I'm pretty sure that the idea for method pointers included both a reference to the method code and a reference to the object. Essentially, it was a closure.
Do you think it's likely, though, that we could openly collaborate on the language definition and get something that's more robust and could be built easily?
That sounds like a good idea. You'd, of course, have final say in what goes in.
Yes, I think the hardware is done, though some minor things may crop up during Spin2 development.
So is this the final FPGA version that will be delivered to treehouse for IC layout? When will be delivered? days, ... weeks?
Or you will not deliver yet the verilog to treehouse until Spin2 development is done? If so, then I hope Spin2 is not 'forum developed' or I guess we will not see the P2 in another 3 or 5 years.
I worry about the cry for types in Spin. We could end up with types for byte, word, long, float, object, structure,... It's going to add complexity to the language. At some point it becomes a nightmare like C++.
Seconded.
until Spin2 development is done?
IMHO, we should get the core up, so we don't miss out on an optimal instruction path, like what was just done. There is no need to complete development.
I wish I had a vision of how we could all collaborate to define the language. It really doesn't need to be that complicated, but parsing all the ideas seems complicated, at the moment. Any of us could go make our own whole language as quickly as we could work together, maybe even quicker. Do you think it's likely, though, that we could openly collaborate on the language definition and get something that's more robust and could be built easily?
That sounds like a worthy goal, and I suspect that at least the braod outlines of the language could be hashed out that way.
These are a few things that are on my mind:
- maybe floating point support built in, somehow
- structures, maybe
- a base Spin language that is not overly tied to the hardware. See the instruction spreadsheet with the Spin procedures for PASM instructions - they provide a bridge to the actual instructions without Spin needing to absorb and repackage everything. This lightens up Spin and encourages PASM programming.
- native code output, at least as an option
- method pointers
- methods can return any number of parameters
- dead code removal (at least unused methods)
I like most of these. I'd make the following suggestions:
- just a few types: int, float, ptr, object, generic (matches any other types). Method variables can be sized (byte, word, long) but locals are always long
- types are inferred by the compiler whenever possible; users can explicitly define them if they want, but they shouldn't have to in most cases
- no need for structures if objects are first class citizens (a structure is just an object that doesn't happen to have methods)
- I think I'd prefer to pass object pointers rather than method pointers
- multiple return values would make a lot of things easier, but what do we allow to be done with them? plain assignment is easy, but should we allow:
[x,y] += func2(a, b)
when func2 returns two values?
(I used square brackets for multiple values rather than round because I think it would make parsing easier.)
Really, Spin2 just needs to be about scope, math/logic, and flow control. It doesn't need to deal with the streamer or anything too specific. It just needs to be a framework for writing code and incorporating objects.
I think that makes a lot of sense.
How important is backwards compatibility? My inclination would be to keep the syntax of Spin and make it pretty much a subset of Spin2.
I think Spin2 needs to have method pointers and structures for sure. I would like some ambiguities and oddities fixed also. Like there are cases where constants from included objects can't be used where they should, etc.
I very much agree with you that the amibuities and oddities should be fixed up. We should take the chance to make Spin2 as clean as possible.
As I think David pointed out earlier, a method pointer means you need to pass both the method and the object -- it's more complicated than a plain C function pointer. Personally I'd like to keep things simple. If we have object pointers I think we can emulate structures and get by without method pointers.
If it supports inline PASM, then can't all the P2 specific things just be done via that? Maybe I'm missing something?
Indeed. I think that what we could do is have a standard library of P2 "instructions" that are implemented via inline functions. This could be optional (and/or broken up into cordic, pinio, etc. objects) so as to reduce namespace clutter.
I think it should also support I2C, SPI, and simple Serial built in, as well as floating point. Any other simple protocols that can be made into builtin methods should be there.
Again I think I'd suggest that these be part of a "standard library" that's part of every Spin distribution, rather than as language features. We should be able to efficiently implement I2C, SPI, and Serial in Spin (particularly if inline PASM is available) so let's do that rather than making the language bigger. It's a subtle distinction, to be sure, since I agree with you that these standard objects should always be available to users.
Floating point may have to be built in, since it affects language syntax more directly (we need floating point constants).
Also, jmg, I am strongly against making PASM more like GAS. PASM is a joy to program in, GAS is dreadful. Just make something to translate from PASM to GAS or vice versa if you really need it.
I agree. I think PASM syntax is much nicer than GAS. We should try to keep the PASM syntax simple, though, and easy for machines to parse.
ersmith,
When I think of Spin/PASM I think of ti as the language + the runtime, because that's essentially what it is. I was thinking the I2C/SPI/etc. stuff would be done similarly to the P2 specific hardware feature stuff. You can call that a standard library if you want, but I think it should be a little more integrated. The compiler can construct a runtime with the bytecode interpreter and various runtime features based on what is in the source. If it all fits in cog/lut then great, if not then it can put some parts in hubexec based on usage or just some predetermined weighting. This is similar to linking in C or other languages, but the compiler currently doesn't separate compiling and linking. In fact they are intermingled.
I think we are mostly in alignment with our thinking, it's just implementation details really.
In the current spin, method calls are in two forms, one is just a call to a method in the same object and just contains an index to that method, the other is a call to a method in another object and contains the index of the other object and the index to the method within it. Since all the objects and methods are in a table at the front of each object, these indices are into those tables. A child object can't reference a parent object in this scheme. I think we need a different mechanism for calling that is more like C, where you call methods by address instead of indirecting through a table. Then function pointers become more powerful/useful. In actual memory, object methods only exist once, the instancing is all done via tables and VAR offsets. Kinda like vtables in C++.
Also, jmg, I am strongly against making PASM more like GAS. PASM is a joy to program in, GAS is dreadful. Just make something to translate from PASM to GAS or vice versa if you really need it.
I agree. I think PASM syntax is much nicer than GAS. We should try to keep the PASM syntax simple, though, and easy for machines to parse.
I'm confused somewhat by claims like 'joy' and 'dreadful', as they are both assembler ?!
Do you have actual, specific examples, of this 'joy' and 'dreadful' ?
To me they are very similar, with PASM having quirks around labels and constants, that are non standard.
Users will be harvesting P2-ASM code from GCC, which does have an optimize engine, so it makes sense to merge the syntax, where practical.
This is why specific examples are always better than non specific opinions.
I'm sure it's brilliant. Small, fast, flexible and all that.
But it's written in x86 assembler! Totally not portable. Ultimately a dead end.
Quite the claim ? Why, exactly ? ( of course, so is PNut, so you avoid that too ?)
Normally, one would avoid coding such tools in assembler, but an assembler itself is something a special case, where 'self-compiling' actually gives an excellent test vehicle.
Also, someone using fasm is going to be targeting x86. fasmg is more general.
I am typing this on a x86 machine - are you saying intel is going broke tomorrow ?
I prefer something I can use now, and "Small, fast, flexible and all that" sounds good to me.
It is open sourced, and I worry less about any over the horizon claims.
"What can I do with this now ?"
Another reality check point : "Intel continued to top all other chip companies in R&D expenditures in 2016 with spending that reached $12.7 billion and represented 22.4% of its semiconductor sales last year."
Maybe, but the far more common case is everyone using PASM written to the cool hardware. This is intended. Makes awesome real time accessible to a lot of people in the same way SPIN does higher level programming.
The OBEX contains some Spin code that implements method pointers for the P1. It's located at http://obex.parallax.com/object/384 . The method pointer points to an array of 4 words that contains the object address, method address, VAR address and number of bytes used by the local stack variables. The VAR address can point to the VAR space of any of the instances of the object, or an independent section of memory that could be used to hold the VAR data.
The MethodPointer code has two ways to set up the method structure. The method SetMethodPtr(methodptr, objnum, methnum) can be used if the object number and method number within the method table are known. Otherwise, SetMethodPtrEx(methodptr) can be used as follows:
if SetMethodPtrEx(@methodstruct)
sample.Example(0, 0, 0)
sample.Example(0, 0, 0) is a dummy call to the target method since SetMethodPtrEx always returns zero. SetMethodPtrEx will extract the method structure data from the Spin bytecodes, and the target method is not called.
This functionality could be built into the Spin language so that the method pointer could be set by just doing methodptr := sample.Example.
Yes, I think the hardware is done, though some minor things may crop up during Spin2 development.
So is this the final FPGA version that will be delivered to treehouse for IC layout? When will be delivered? days, ... weeks?
Or you will not deliver yet the verilog to treehouse until Spin2 development is done? If so, then I hope Spin2 is not 'forum developed' or I guess we will not see the P2 in another 3 or 5 years.
Verilog would be delivered way before Spin2 is finished.
Byte-code engine testing is all that is needed to confirm opcode/silicon coverage.
Personally, I would like to see that testing include XIP from QuadSPI and HyperRAM parts, as a 'softer code ceiling' will help P2 sales.
Users will be harvesting P2-ASM code from GCC, which does have an optimize engine, so it makes sense to merge the syntax, where practical.
As far as I know there is no optimizing going on when using assembler with GCC.
Quite the claim ? Why, exactly ?
What if one is not using an x86 based machine? A Raspberry Pi for example.
...is PNut, so you avoid that too ?
It aviods me. See above.
...are you saying intel is going broke tomorrow
Certainly not. That would be silly.
As it stands OpenSpin, can be compiled for use on ARM machines, like the Raspi. It can be transpiled to Javascript to create an in browser Propeller IDE. In the near future it will be usable on RISC V machines. Or whatever comes along.
Meany while fasmg is stuck on Intel.
Perhaps you don't care about cross-platform support. I do.
Do you think it's likely, though, that we could openly collaborate on the language definition and get something that's more robust and could be built easily?
That sounds like a good idea. You'd, of course, have final say in what goes in.
Also, Heater, Chip will be using what he knows, x86 assembler for the compiler he makes, just as before. However, the plan is to have it ported to C/C++, as I did with OpenSpin, as early as possible. Hopefully, before launch of the chip. I have seen some early version of the x86 stuff for P2 (pre Spin2), and there are large chunks that are the same as before, and also a lot of familiar stuff even in the new areas. So, it should come along quicker this time around.
Is there a desire to have the equivalent of the current pnut.exe but as cross platform C/C++ instead? I could try to get that going if Chip is game and there is enough desire for it?
jmg,
Perhaps you don't care about cross-platform support. I do.
I have to agree. Going cross-platform now will save the time of having to go cross-platform later.
... but it will also delay the tools release.
Parallax will have to choose which is more important, real product shipments, or nice to have tick boxes...
I think you have all the keys needed to make Spin2.
When I first read this I thought you meant you were considering the suggestion that Parallax might adopt spin2cpp/fastspin as the official Spin2 compiler. On second reading I don't think that is clear. Are you suggesting that we can all go off and do our own implementations but that we should collaborate on the language definition itself? Are you still planning to create an x86 implementation?
Has the idea of writing the official Spin 2 compiler in Spin 2 for x86 been discussed properly yet? If a least-common-denominator version of Spin 2 that can run on things other than the Propeller is going to be written, then it should be self hosting. What would be the best way to bootstrap such a thing?
Comments
What we need pointers/references to objects. With that a method call is just a dot away, "someObjectInstance.someMethod(param, ...)"
I worry about the cry for types in Spin. We could end up with types for byte, word, long, float, object, structure,... It's going to add complexity to the language. At some point it becomes a nightmare like C++.
I'm not convinced that being able to call C from Spin or vice versa is necessary. Can't we just arrange to run C/C++ in a COG and have it exchange messages with Spin running in another COG?
Speaking of messages. What about having some kind of message exchange channel/mail box system baked into the language itself. Such a standard would make interoperating with other languages easier. This has been a bit of a stumbling block in the P1. Recycling Spin objects that are mostly PASM for use from C was troublesome.
That is the plan Roy. SPIN2 should be lean, not so hardware dependent.
Inline all the P2, and allow for PASM procedures in addition to the usual whole COG DAT PASM Present now.
So is this the final FPGA version that will be delivered to treehouse for IC layout? When will be delivered? days, ... weeks?
Or you will not deliver yet the verilog to treehouse until Spin2 development is done? If so, then I hope Spin2 is not 'forum developed' or I guess we will not see the P2 in another 3 or 5 years.
Seconded.
IMHO, we should get the core up, so we don't miss out on an optimal instruction path, like what was just done. There is no need to complete development.
I like most of these. I'd make the following suggestions:
- just a few types: int, float, ptr, object, generic (matches any other types). Method variables can be sized (byte, word, long) but locals are always long
- types are inferred by the compiler whenever possible; users can explicitly define them if they want, but they shouldn't have to in most cases
- no need for structures if objects are first class citizens (a structure is just an object that doesn't happen to have methods)
- I think I'd prefer to pass object pointers rather than method pointers
- multiple return values would make a lot of things easier, but what do we allow to be done with them? plain assignment is easy, but should we allow: when func2 returns two values?
(I used square brackets for multiple values rather than round because I think it would make parsing easier.)
I think that makes a lot of sense.
How important is backwards compatibility? My inclination would be to keep the syntax of Spin and make it pretty much a subset of Spin2.
Eric
As I think David pointed out earlier, a method pointer means you need to pass both the method and the object -- it's more complicated than a plain C function pointer. Personally I'd like to keep things simple. If we have object pointers I think we can emulate structures and get by without method pointers.
Indeed. I think that what we could do is have a standard library of P2 "instructions" that are implemented via inline functions. This could be optional (and/or broken up into cordic, pinio, etc. objects) so as to reduce namespace clutter.
Again I think I'd suggest that these be part of a "standard library" that's part of every Spin distribution, rather than as language features. We should be able to efficiently implement I2C, SPI, and Serial in Spin (particularly if inline PASM is available) so let's do that rather than making the language bigger. It's a subtle distinction, to be sure, since I agree with you that these standard objects should always be available to users.
Floating point may have to be built in, since it affects language syntax more directly (we need floating point constants).
I agree. I think PASM syntax is much nicer than GAS. We should try to keep the PASM syntax simple, though, and easy for machines to parse.
Regards,
Eric
When I think of Spin/PASM I think of ti as the language + the runtime, because that's essentially what it is. I was thinking the I2C/SPI/etc. stuff would be done similarly to the P2 specific hardware feature stuff. You can call that a standard library if you want, but I think it should be a little more integrated. The compiler can construct a runtime with the bytecode interpreter and various runtime features based on what is in the source. If it all fits in cog/lut then great, if not then it can put some parts in hubexec based on usage or just some predetermined weighting. This is similar to linking in C or other languages, but the compiler currently doesn't separate compiling and linking. In fact they are intermingled.
I think we are mostly in alignment with our thinking, it's just implementation details really.
In the current spin, method calls are in two forms, one is just a call to a method in the same object and just contains an index to that method, the other is a call to a method in another object and contains the index of the other object and the index to the method within it. Since all the objects and methods are in a table at the front of each object, these indices are into those tables. A child object can't reference a parent object in this scheme. I think we need a different mechanism for calling that is more like C, where you call methods by address instead of indirecting through a table. Then function pointers become more powerful/useful. In actual memory, object methods only exist once, the instancing is all done via tables and VAR offsets. Kinda like vtables in C++.
I'm confused somewhat by claims like 'joy' and 'dreadful', as they are both assembler ?!
Do you have actual, specific examples, of this 'joy' and 'dreadful' ?
To me they are very similar, with PASM having quirks around labels and constants, that are non standard.
Users will be harvesting P2-ASM code from GCC, which does have an optimize engine, so it makes sense to merge the syntax, where practical.
This is why specific examples are always better than non specific opinions.
Quite the claim ? Why, exactly ? ( of course, so is PNut, so you avoid that too ?)
Normally, one would avoid coding such tools in assembler, but an assembler itself is something a special case, where 'self-compiling' actually gives an excellent test vehicle.
Also, someone using fasm is going to be targeting x86. fasmg is more general.
I am typing this on a x86 machine - are you saying intel is going broke tomorrow ?
I prefer something I can use now, and "Small, fast, flexible and all that" sounds good to me.
It is open sourced, and I worry less about any over the horizon claims.
"What can I do with this now ?"
Another reality check point :
"Intel continued to top all other chip companies in R&D expenditures in 2016 with spending that reached $12.7 billion and represented 22.4% of its semiconductor sales last year."
Maybe, but the far more common case is everyone using PASM written to the cool hardware. This is intended. Makes awesome real time accessible to a lot of people in the same way SPIN does higher level programming.
The MethodPointer code has two ways to set up the method structure. The method SetMethodPtr(methodptr, objnum, methnum) can be used if the object number and method number within the method table are known. Otherwise, SetMethodPtrEx(methodptr) can be used as follows:
if SetMethodPtrEx(@methodstruct) sample.Example(0, 0, 0)sample.Example(0, 0, 0) is a dummy call to the target method since SetMethodPtrEx always returns zero. SetMethodPtrEx will extract the method structure data from the Spin bytecodes, and the target method is not called.This functionality could be built into the Spin language so that the method pointer could be set by just doing methodptr := sample.Example.
Byte-code engine testing is all that is needed to confirm opcode/silicon coverage.
Personally, I would like to see that testing include XIP from QuadSPI and HyperRAM parts, as a 'softer code ceiling' will help P2 sales.
P2 already supports C 'well enough'.
As it stands OpenSpin, can be compiled for use on ARM machines, like the Raspi. It can be transpiled to Javascript to create an in browser Propeller IDE. In the near future it will be usable on RISC V machines. Or whatever comes along.
Meany while fasmg is stuck on Intel.
Perhaps you don't care about cross-platform support. I do.
Perhaps Chip could be added to that list : https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
x byte "Hello" + "world"
Which results in 9 bytes the middle on of which is the sum of the binary versions of 'o' and 'w'.
Probably a harmless oddity but useless and weird.
I have to agree. Going cross-platform now will save the time of having to go cross-platform later.
For example, just look at the IDE mess we have right now. If only Propeller Tool would have been cross-platform from the start...
x byte "Hell", "o" + "w", "orld"
Okay, should've been flagged as a syntax error.
-Phil
A correct result might be a syntax error. Or define "+" as string concatenation in this case.
-Phil
That is one I didn't know about, but Phil is, of course, right about how it's being treated.
I also agree with Phil that it should be considered an error in the Spin context.
Is there a desire to have the equivalent of the current pnut.exe but as cross platform C/C++ instead? I could try to get that going if Chip is game and there is enough desire for it?
... but it will also delay the tools release.
Parallax will have to choose which is more important, real product shipments, or nice to have tick boxes...
yet you claimed "Ultimately a dead end", Raspberry Pi is a niche, and will likely never run FPGA tools.
Would you suggest Chip cease using Verilog today, merely because it is "Totally not portable"
We just have to get along with our different opinions. True. It was only an example. No.
Sadly a lot of the worlds software is welded to x86 and Windows. Pragmatically we have to deal with that.
Does not mean we have to follow along.