So, byte and word are already unsigned and only long is signed, right?
Maybe the interpreter could be used for other languages too?
Won't the unusual calling sequence make it difficult to use for languages like C?
I think the "call @ptr" opcode could be used. Is that right, Chip? Could a function drop anchor, compute an address on the stack, and then call the bytecode at that address via "call @ptr"?
I find the Spin (and Spin2) interpreter calling conventions hard to wrap my head around. I'm more used to assembly language style calling conventions, where to call a function you just need its address. So I'm really hoping "call @ptr" does what I think it does.
So, byte and word are already unsigned and only long is signed, right?
Maybe the interpreter could be used for other languages too?
Won't the unusual calling sequence make it difficult to use for languages like C?
I think the "call @ptr" opcode could be used. Is that right, Chip? Could a function drop anchor, compute an address on the stack, and then call the bytecode at that address via "call @ptr"?
I find the Spin (and Spin2) interpreter calling conventions hard to wrap my head around. I'm more used to assembly language style calling conventions, where to call a function you just need its address. So I'm really hoping "call @ptr" does what I think it does.
Eric
It has to provide two longs of setup info: pbase, vbase, and pub/sub index. I think. Need to look at it.
Maybe the interpreter could be used for other languages too?
Oh, I'm sure the core elements will be used many times.
You may have seen my comment in your other thread, around a their frontend/ this backend (tweaked as needed) merger, to create a Prop 2 Python
Python has its own bytecode, based on its very different needs (it's a dynamically typed language) so I doubt the Spin2 interpreter would be applicable there. Some of Chip's optimization techniques will obviously be useful for any bytecode interpreter, of course
Yes, The use of 'tweaked' was more ironical, but the core use of XBYTE type packing & other optimization techniques/examples will be invaluable.
So, byte and word are already unsigned and only long is signed, right?
Maybe the interpreter could be used for other languages too?
Won't the unusual calling sequence make it difficult to use for languages like C?
I think the "call @ptr" opcode could be used. Is that right, Chip? Could a function drop anchor, compute an address on the stack, and then call the bytecode at that address via "call @ptr"?
I find the Spin (and Spin2) interpreter calling conventions hard to wrap my head around. I'm more used to assembly language style calling conventions, where to call a function you just need its address. So I'm really hoping "call @ptr" does what I think it does.
Eric
It has to provide two longs of setup info: pbase, vbase, and pub/sub index. I think. Need to look at it.
What is the advantage of all of these base addresses? I assume Eric's Spin compiler gets by without them. Do they allow for code compression or something?
It has to provide two longs of setup info: pbase, vbase, and pub/sub index. I think. Need to look at it.
What is the advantage of all of these base addresses? I assume Eric's Spin compiler gets by without them. Do they allow for code compression or something?
I think, if I understand it right, that vbase is the same as what my compiler calls objbase, namely a pointer to the per-object data (the things declared in VAR). That will need to be set up no matter what, although many compilers just make it the first parameter to any called methods. I'm more foggy on pbase; it's like a C++ vtable, I think (pointer to a table of method pointers) but Spin doesn't actually have dynamic dispatch so I'm not sure what it's function is.
In my MethodPtr object for the P1 I used vbase, pbase, pcurr and doffset. doffset is the number of bytes used for local variables on the stack. However, vbase, pbase and the method index would work also since pcurr and doffset are contained in the object's method table.
In my MethodPtr object for the P1 I used vbase, pbase, pcurr and doffset. doffset is the number of bytes used for local variables on the stack. However, vbase, pbase and the method index would work also since pcurr and doffset are contained in the object's method table.
I don't doubt that they are all needed for the current interpreter design but why not simplify things?
It's true that my comment is based on the P1 interpreter. The P2 interpreter could be completely different. The allocation of VAR space may be handled differently, and maybe the called routine could handle the space for local stack variables so the caller doesn't need to know about it.
Wikipedia on CPU is interesting. Suggests CPU==core
But, the "socket" think is just wrong, right?
Some computers employ a multi-core processor, which is a single chip containing two or more CPUs called "cores"; in that context, one can speak of such single chips as "sockets".
Some computers employ a multi-core processor, which is a single chip containing two or more CPUs called "cores"; in that context, one can speak of such single chips as "sockets".
There is also a faithfull serf of her majesty, the queen (to don't say it's part of her "crowded" belly); is it, the Cordic Solver, kind of a Chancellor of the Exchequer, keeping sane (and stream-lined) the hive high maths.
Comments
I haven't run it lately to see if the bytecode program works. I only know that the program assembles okay.
I think the "call @ptr" opcode could be used. Is that right, Chip? Could a function drop anchor, compute an address on the stack, and then call the bytecode at that address via "call @ptr"?
I find the Spin (and Spin2) interpreter calling conventions hard to wrap my head around. I'm more used to assembly language style calling conventions, where to call a function you just need its address. So I'm really hoping "call @ptr" does what I think it does.
Eric
It has to provide two longs of setup info: pbase, vbase, and pub/sub index. I think. Need to look at it.
I think, if I understand it right, that vbase is the same as what my compiler calls objbase, namely a pointer to the per-object data (the things declared in VAR). That will need to be set up no matter what, although many compilers just make it the first parameter to any called methods. I'm more foggy on pbase; it's like a C++ vtable, I think (pointer to a table of method pointers) but Spin doesn't actually have dynamic dispatch so I'm not sure what it's function is.
counters are a good example of where you want unsigned longs... That is something that is a bit awkward in Spin...
I did not say it's confusing, I said in makes no sense. From the definition of "core":
core - the part of something that is central to its existence or character
Well, if there are many of them all similar and all running on an equal footing then none of them is core.
I'm happier with "core", the way people understand it now, than cog.
But, the "socket" think is just wrong, right?
I think that terminology usage comes from the motherboards niche sector, where there are Intel socket XYQZ etc
https://en.wikipedia.org/wiki/CPU_socket
With it's "honey sweet" instruction set.
Perhaps it could be 1 hive, 8 queen bees, and 64 smart worker bees?
Drones? Workers?
Maybe the hub could be considered the queen, since a hive can only have one.
There are 8 smart worker bees, who work next to the queen. They do all the thinking. This way, men still have a prominent role.
that means the female worker brood bees are the 64 smart pins
.. and that can happen, as each one has a a unique windowed access to the Queen !
Learning a bit about bees today...
Perhaps this chip should be called B2, rather than P2
The rest of the world knows what we call cogs as cores.
The smart pins are not enough to be a core really, but some would call them that. I think it's best to just leave them as smart pins.
The bee business is hilarious!
No other chip has one of those.
How about SWARM, then. Wait, that has ARM in it.
The Propeller Hive project has been going on for 10 years!
http://forums.parallax.com/discussion/108848/hive-the-24-core-retro-style-computer-kit/p1