New Spin

2456736

Comments

  • Roy Eltham wrote: »
    If all locals/params are in LUT space then you can't use them to be passed to another COGs new/init.

    Perhaps we can have a way to say what memory we want locals/params in? Otherwise we are forced to only use globals...

    Can you give an example?
  • 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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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.
  • cgracey wrote: »
    Roy Eltham wrote: »
    If all locals/params are in LUT space then you can't use them to be passed to another COGs new/init.

    Perhaps we can have a way to say what memory we want locals/params in? Otherwise we are forced to only use globals...

    Can you give an example?
    I posted one above. I think it is common practice on P1.

  • It's common practice to make everything global too.
    $50,000 buys you a discrediting of a journalist
  • 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.




  • evanh wrote: »
    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.

  • Ah, how about a new PRIVATE class of variables that exist in HubRAM like locals currently do on the Prop1's Spin.
    $50,000 buys you a discrediting of a journalist
  • If I understand the issue correctly:

    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?

  • Heater. wrote: »
    If I understand the issue correctly:

    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.

  • Heater.Heater. Posts: 19,176
    edited February 18 Vote Up0Vote Down
    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.

  • Heater. wrote: »
    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.
  • Cluso99Cluso99 Posts: 12,584
    edited February 18 Vote Up0Vote Down
    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.

    Am I missing something here ???
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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.
  • Heater. wrote: »
    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.
  • RaymanRayman Posts: 8,201
    edited February 18 Vote Up0Vote Down
    Could have different compile options for P2 Spin?

    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...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Could have different compile options for P2 Spin?

    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.
  • MikeDYurMikeDYur Posts: 1,956
    edited February 18 Vote Up0Vote Down
    Since New Spin would not be backwards compatible with the P1, how will it be differentiated, what will the extension be?

    We have: example.bs1, example.bs2, example.spin, maybe example.spn2 would be clear enough.
  • 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?
  • Brian,

    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.



  • That is the way is should be.

    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.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • 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.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 20,987
    edited February 18 Vote Up0Vote Down
    David Betz wrote:
    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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Heater. wrote: »
    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.

    What am I missing here other than semantics ???
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • The AVR microcontroller architecture was optimized from the ground up for C.

    I was curious about that so found this paper:

    http://ugweb.cs.ualberta.ca/~c274/resources/hardware/Atmel/CompilerProcessorCoDesign.pdf

  • David Betz wrote:
    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.
  • Spud,
    That is the way is should be.
    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 :)

  • Phil Pilgrim,
    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.

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 20,987
    edited February 18 Vote Up0Vote Down
    David Betz wrote:
    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.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
Sign In or Register to comment.