I would expect globals to be in hub as they are now.
Locals are just that, locals. You never pass them to external routines or other cogs, so there is no problem with them being in lut.
Globals on the other hand, are likely to be large buffers that are not only shared between routines, but also likely to be shared with other cogs. Therefore they would not work in lut space anyway.
Chip,
When you do a cognew/init you pass in the value to go in PAR, and currently you can pass in the address of a any variable and since they are all in HUB it works. If some variables are not in hub then you can't pass the address of them into cognew/init.
I would like to request a standard grammar ( ANTLR compatible or similar ) and well documented symbol table generator be baked into the new SPIN to help 3rd party tool providers support the P2.
It's common practice to make everything global too.
Globals have the problem that if more than one COG tries to use them at the same time you run into conflicts. I guess we could have a malloc/free concept and used heap allocated objects for those cases. That's starting to seem too much like C though.
1) Spin/PASM running in a COG cannot read the LUT of other COGS.
2) The suggestion is to put Spin's stack in the LUT of the COG running it. All local variables will be in LUT.
3) Therefore local variables cannot be passed, via PAR, some mailbox, or whatever, from Spin in one COG to Spin/PASM running in another COG.
This sure sounds like it would break things like the float 32 objects.
1) Spin/PASM running in a COG cannot read the LUT of other COGS.
2) The suggestion is to put Spin's stack in the LUT of the COG running it. All local variables will be in LUT.
3) Therefore local variables cannot be passed, via PAR, some mailbox, or whatever, from Spin in one COG to Spin/PASM running in another COG.
This sure sounds like it would break things like the float 32 objects.
Or am I missing a point here?
I think you've got it exactly right. I guess new paradigms need to be invented for P2.
When people talk of "globals" here do they mean global to all functions in an object or global to all objects.
The former is normal. They are object properties. The later is loathsome as it break encapsulation. All of a sudden my object and your object are not usable together if they happen to use the same names.
In terms of conflicting access to data by multiple COGs I don't that it makes any difference if that data is global, and object property or a local variable. You need to ensure mutual exclusion no matter what.
When people talk of "globals" here do they mean global to all functions in an object or global to all objects.
The former is normal. They are object properties. The later is loathsome as it break encapsulation. All of a sudden my object and your object are not usable together if they happen to use the same names.
In terms of conflicting access to data by multiple COGs I don't that it makes any difference if that data is global, and object property or a local variable. You need to ensure mutual exclusion no matter what.
Actually, you're right. These could be global to a single object. Aren't there instances of VAR variables for each object instance? I guess that would work assuming they are located in hub memory.
I like to think of VAR as being "instance" or "object" properties. Every instance of a Spin object gets its own. Things in DAT are "class" properties. All instances of a Spin object share the same ones.
Spin does not have globals at all currently. Except some Prop config things, which is fair enough.
The terminology is a bit muddled because Spin does not have "classes". "object" gets used to talk about the source/bytecode that implements them and about the actual instances at run time.
The following generates local variables
Pub/Pri someroutine(passedvariable/s) | localvariable1, local2, etc
These localvariable1, etc are local to the Pub/Pri routine only, so there is no issue in them being in LUT. Nothing outside this routine can access these local variables. The next routine can even declare it's local variables with the same name.
Btw there are two possible ways for globals to be declared. One set is contained within a VAR section, and the other is within a DAT section. Both of these are in hub and will be used from there, not from LUT.
VAR globals get repeated for objects declared multiple times, whereas DAT globals are only defined as a single set even if the object is declared multiple times.
Neither variable in DAT or VAR are "global" as the term is generally used. Even if they do end up sitting in HUB memory.
They private to the instance of an object, VAR, or private to all instances of an object, DAT. They are not visible to other different objects.
One can of pass pointers to them to methods in other objects if one wants to share them.
These localvariable1, etc are local to the Pub/Pri routine only, so there is no issue in them being in LUT.
There is. I cannot pass a pointer to variables in LUT to methods of another object, same type or different type, running on another COG. That COG cannot see inside my LUT.
I cannot write pointers to those local variables in LUT to any inter-COG mailbox for the same reason.
Neither variable in DAT or VAR are "global" as the term is generally used. Even if they do end up sitting in HUB memory.
They private to the instance of an object, VAR, or private to all instances of an object, DAT. They are not visible to other different objects.
One can of pass pointers to them to methods in other objects if one wants to share them.
These localvariable1, etc are local to the Pub/Pri routine only, so there is no issue in them being in LUT.
There is. I cannot pass a pointer to variables in LUT to methods of another object, same type or different type, running on another COG. That COG cannot see inside my LUT.
I cannot write pointers to those local variables in LUT to any inter-COG mailbox for the same reason.
That is exactly what I was trying to say maybe not that effectively.
Bytecode might be good for the baby versions of P2.
But, memory seems pretty huge to me and might be nice to have Spin that compiles to something faster...
On the other hand, maybe C will be around soon for that...
Depending on how much Chip changes Spin for Spin2, I imagine Eric is likely to update his compiler to match whatever Chip does. That should be faster than the byte code interpreter for programs that will fit in hub RAM.
So this is a new language, with the same name as an existing one, that isn't backwards compatible; for a processor that doesn't exist yet which is based on a design that isn't proven yet? Or am I missing something?
There is no way Spin on the P2 can be compatible with Spin on the P1 because Spin includes the ability to write PASM into your objects. I'm sure there is no way that P1 PASM can work without change on the P2. What with all the other hardware and memory layout changes I think backwards compatibility is impossible.
Of course it may not have the same name. Could be "Spin II", "Spin 2" or "New Spin" as in this thread title.
One of the best things about a Propeller is the unified purpose built design. A Prop, SPIN and PASM are a singular thing. I realize this conflicts with norms, portability and a lot of other perfectly valid ideas.
Here is the thing about that: A lot of us want that to exist.
A P2 is very different and more than A P1. The singular environment should reflect that.
As for portability, etc... when a P2 is used as intended, that code is going to be specific and there should be this unified environment to get right at that, lean, accessible, and potent.
There will be the usual stuff that works in the usual ways.
I'm not sure that a language that closely tied to a specific chip makes much sense. One reason people hesitated to use P1 was that they had to learn an entirely new language. Now you're saying that even people who already know P1 will need to learn a noticeably different language just to use the P2. Isn't the whole point of a high-level language to abstract away the low-level details of the underlying machine architecture? It seems to me that Spin2 should be as similar to Spin as possible.
Isn't the whole point of a high-level language to abstract away the low-level details of the underlying machine architecture? It seems to me that Spin2 should be as similar to Spin as possible.
That depends upon the architecture the language is being designed for. The AVR microcontroller architecture was optimized from the ground up for C. So C is the appropriate native language for the AVR. But if a micro's architecture is complete unique, it deserves -- yea, demands -- its own special HLL for best performance. IOW, some unique architectural features can't be abstracted away for the sake of compatibility without considerable compromise.
Neither variable in DAT or VAR are "global" as the term is generally used. Even if they do end up sitting in HUB memory.
They private to the instance of an object, VAR, or private to all instances of an object, DAT. They are not visible to other different objects.
One can of pass pointers to them to methods in other objects if one wants to share them.
These localvariable1, etc are local to the Pub/Pri routine only, so there is no issue in them being in LUT.
There is. I cannot pass a pointer to variables in LUT to methods of another object, same type or different type, running on another COG. That COG cannot see inside my LUT.
I cannot write pointers to those local variables in LUT to any inter-COG mailbox for the same reason.
Currently, where do you pass the address of a local variable? I cannot think of any case. It's a variable only used by that Pub/Pri method. So it does not matter if this local variable is in LUT. Typically we define local variables such as i, j, etc.
I get your point that VAR and DAT variables are not truly globals as they are only accessible within the current object. We can pass the addresses of these to lower level objects. They will still be in HUB so there is no difference here either.
One of the things we couldn't do was get the hub address at compile time so that's where @@@ was added into the bst and homespun compilers.
Isn't the whole point of a high-level language to abstract away the low-level details of the underlying machine architecture? It seems to me that Spin2 should be as similar to Spin as possible.
That depends upon the architecture the language is being designed for. The AVR microcontroller architecture was optimized from the ground up for C. So C is the appropriate native language for the AVR. But if a micro's architecture is complete unique, it deserves -- yea, demands -- its own special HLL for best performance. IOW, some unique architectural features can't be abstracted away for the sake of compatibility without considerable compromise.
-Phil
I think Spin itself is a counter example to your claim. It compiles to a stack machine but the Propeller has no stack. It certainly abstracts the hardware except where PASM is used.
I am hopefully expecting that Spin on the P2 works the same as Spin on the P1. Except...
1) Anything to do with PASM. Or P1 hardware specific builtin functions.
2) A pile of new builtin functions to deal with new/different hardware features.
3) Perhaps some new high level language features. That don't break old high level Spin syntax/semantics.
That is to say, the high level language features of Spin stay the same. The low level machine dependent parts change.
I'm sure there are many Prop users out there who have never used PASM. What they need to allow them to use the P2 is the same Spin language. They also need objects with the same API's to replace all they ones they have used in their P1 projects and become used to.
That is the way is should be.
That at least puts Spin on the same level as C. We use the same C language on devices from AVR to Raspberry Pi, to Windows PC's to super computers. But as many have noted, when working in the low level world of micro-controllers the environments are very different and we cannot expect to be able to move C projects on Arduino to the Raspberry Pi or anywhere easily. For example.
As a case in point, my first run at making an Intel 8080 emulator was written in Spin. Horribly slow but at least I could check if I was getting the 8080 logic right. I think it only used FDS. There was no PASM or other hardware dependency. That kind of code should run the same onthe P2. Only faster
That depends upon the architecture the language is being designed for. The AVR microcontroller architecture was optimized from the ground up for C. So C is the appropriate native language for the AVR
Perhaps the AVR was made "C friendly". I don't see what that has to do with Spin and the Propeller. Spin is compiled to a byte code. That byte code is run by a virtual machine on the Propeller. The Spin language does not reflect the hardware architecture of the Propeller at all.
I think Spin itself is a counter example to your claim. It compiles to a stack machine but the Propeller has no stack. It certainly abstracts the hardware except where PASM is used.
That's a pretty insignifcant exception, considering the proliferation on non-standard operators like <# and ><, plus cognew, waitcnt, waitpe, and other language features tailored to the Prop's unique architecture. To implement those in C, for example, has required some pretty awkward contortions, IMO.
Comments
Can you give an example?
Locals are just that, locals. You never pass them to external routines or other cogs, so there is no problem with them being in lut.
Globals on the other hand, are likely to be large buffers that are not only shared between routines, but also likely to be shared with other cogs. Therefore they would not work in lut space anyway.
When you do a cognew/init you pass in the value to go in PAR, and currently you can pass in the address of a any variable and since they are all in HUB it works. If some variables are not in hub then you can't pass the address of them into cognew/init.
1) Spin/PASM running in a COG cannot read the LUT of other COGS.
2) The suggestion is to put Spin's stack in the LUT of the COG running it. All local variables will be in LUT.
3) Therefore local variables cannot be passed, via PAR, some mailbox, or whatever, from Spin in one COG to Spin/PASM running in another COG.
This sure sounds like it would break things like the float 32 objects.
Or am I missing a point here?
The former is normal. They are object properties. The later is loathsome as it break encapsulation. All of a sudden my object and your object are not usable together if they happen to use the same names.
In terms of conflicting access to data by multiple COGs I don't that it makes any difference if that data is global, and object property or a local variable. You need to ensure mutual exclusion no matter what.
Spin does not have globals at all currently. Except some Prop config things, which is fair enough.
The terminology is a bit muddled because Spin does not have "classes". "object" gets used to talk about the source/bytecode that implements them and about the actual instances at run time.
Pub/Pri someroutine(passedvariable/s) | localvariable1, local2, etc
These localvariable1, etc are local to the Pub/Pri routine only, so there is no issue in them being in LUT. Nothing outside this routine can access these local variables. The next routine can even declare it's local variables with the same name.
Btw there are two possible ways for globals to be declared. One set is contained within a VAR section, and the other is within a DAT section. Both of these are in hub and will be used from there, not from LUT.
VAR globals get repeated for objects declared multiple times, whereas DAT globals are only defined as a single set even if the object is declared multiple times.
Am I missing something here ???
They private to the instance of an object, VAR, or private to all instances of an object, DAT. They are not visible to other different objects.
One can of pass pointers to them to methods in other objects if one wants to share them.
There is. I cannot pass a pointer to variables in LUT to methods of another object, same type or different type, running on another COG. That COG cannot see inside my LUT.
I cannot write pointers to those local variables in LUT to any inter-COG mailbox for the same reason.
Bytecode might be good for the baby versions of P2.
But, memory seems pretty huge to me and might be nice to have Spin that compiles to something faster...
On the other hand, maybe C will be around soon for that...
We have: example.bs1, example.bs2, example.spin, maybe example.spn2 would be clear enough.
That is about the size of it.
There is no way Spin on the P2 can be compatible with Spin on the P1 because Spin includes the ability to write PASM into your objects. I'm sure there is no way that P1 PASM can work without change on the P2. What with all the other hardware and memory layout changes I think backwards compatibility is impossible.
Of course it may not have the same name. Could be "Spin II", "Spin 2" or "New Spin" as in this thread title.
One of the best things about a Propeller is the unified purpose built design. A Prop, SPIN and PASM are a singular thing. I realize this conflicts with norms, portability and a lot of other perfectly valid ideas.
Here is the thing about that: A lot of us want that to exist.
A P2 is very different and more than A P1. The singular environment should reflect that.
As for portability, etc... when a P2 is used as intended, that code is going to be specific and there should be this unified environment to get right at that, lean, accessible, and potent.
There will be the usual stuff that works in the usual ways.
Let Chip be Chip. It matters that this happens.
-Phil
I get your point that VAR and DAT variables are not truly globals as they are only accessible within the current object. We can pass the addresses of these to lower level objects. They will still be in HUB so there is no difference here either.
One of the things we couldn't do was get the hub address at compile time so that's where @@@ was added into the bst and homespun compilers.
What am I missing here other than semantics ???
I was curious about that so found this paper:
http://ugweb.cs.ualberta.ca/~c274/resources/hardware/Atmel/CompilerProcessorCoDesign.pdf
1) Anything to do with PASM. Or P1 hardware specific builtin functions.
2) A pile of new builtin functions to deal with new/different hardware features.
3) Perhaps some new high level language features. That don't break old high level Spin syntax/semantics.
That is to say, the high level language features of Spin stay the same. The low level machine dependent parts change.
I'm sure there are many Prop users out there who have never used PASM. What they need to allow them to use the P2 is the same Spin language. They also need objects with the same API's to replace all they ones they have used in their P1 projects and become used to.
That is the way is should be.
That at least puts Spin on the same level as C. We use the same C language on devices from AVR to Raspberry Pi, to Windows PC's to super computers. But as many have noted, when working in the low level world of micro-controllers the environments are very different and we cannot expect to be able to move C projects on Arduino to the Raspberry Pi or anywhere easily. For example.
As a case in point, my first run at making an Intel 8080 emulator was written in Spin. Horribly slow but at least I could check if I was getting the 8080 logic right. I think it only used FDS. There was no PASM or other hardware dependency. That kind of code should run the same onthe P2. Only faster
-Phil