But have some conclusions -- Why people complain that in P1 it function in other way that in P2 --- It was said from start P2 will not be 100% code compatible.
Now one question to Chip.
For me simple schematic say much more that 1000 words -- so question is:
Can You provide us with simple Block schematic to I/O pins - If possible even to Counters.
That can simplify understanding and give all info to use that parts most effectively.
But have some conclusions -- Why people complain that in P1 it function in other way that in P2 --- It was said from start P2 will not be 100% code compatible.
Now one question to Chip.
For me simple schematic say much more that 1000 words -- so question is:
Can You provide us with simple Block schematic to I/O pins - If possible even to Counters.
That can simplify understanding and give all info to use that parts most effectively.
I must make some block diagrams of these circuits. I will try to get this done soon - particularly the I/O pin diagram, since it's a lot simpler. I've been busy working on the Spin2 interpreter for a while now, and I haven't made any new documentation lately.
About function "mega-pointers": I found a way to fit them into two longs. A function pointer must include a 32-bit pbase and a 32-bit vbase, along with an 8-bit pub/pri index. It turns out that because pbase and vbase are quad-aligned in Spin2, both have %0000 in the bottom nibble. There are the 8 bits needed to store the pub/pri index!
I must make some block diagrams of these circuits. I will try to get this done soon - particularly the I/O pin diagram, since it's a lot simpler. I've been busy working on the Spin2 interpreter for a while now, and I haven't made any new documentation lately.
About function "mega-pointers": I found a way to fit them into two longs. A function pointer must include a 32-bit pbase and a 32-bit vbase, along with an 8-bit pub/pri index. It turns out that because pbase and vbase are quad-aligned in Spin2, both have %0000 in the bottom nibble. There are the 8 bits needed to store the pub/pri index!
I'm still not sure I understand how the Spin interpreter works. Is VBASE a pointer to the base of variables associated with an object instance and PBASE is the base of a table of methods for that object? In that case, an object pointer would just be the two of those?
I'm still not sure I understand how the Spin interpreter works. Is VBASE a pointer to the base of variables associated with an object instance and PBASE is the base of a table of methods for that object? In that case, an object pointer would just be the two of those?
That's all correct, but if you are calling out a method within that object (to make a "mega-pointer"), you need another 8 bits for the method's index value.
That's all correct, but if you are calling out a method within that object (to make a "mega-pointer"), you need another 8 bits for the method's index value.
That's good. I'm impressed with how well you guys do with your inferences and extrapolations. I'm horrible at understanding how other people do things.
This mega-pointer might seem kind of arbitrary in its purpose and composition, but the key is that it can be compiled with limited scope and resolve final details at run-time. Just a pointer to an object would need a lot more compile-time awareness to make use of.
That's good. I'm impressed with how well you guys do with your inferences and extrapolations. I'm horrible at understanding how other people do things.
This mega-pointer might seem kind of arbitrary in its purpose and composition, but the key is that it can be compiled with limited scope and resolve final details at run-time. Just a pointer to an object would need a lot more compile-time awareness to make use of.
But you must have types in the symbol table for things declared in the OBJ section. Couldn't you just keep track of the types of function/method parameters as well? That way you could pass a reference to an object to a function/method by just passing the VBASE of the object and inferring the PBASE from the type.
Edit: Actually, forget this idea. Object references really aren't that useful unless you also support inheritance and virtual functions and that would complicate Spin too much I think. Sorry for the distraction!
Chip said: About function "mega-pointers": I found a way to fit them into two longs. A function pointer must include a 32-bit pbase and a 32-bit vbase, along with an 8-bit pub/pri index. It turns out that because pbase and vbase are quad-aligned in Spin2, both have %0000 in the bottom nibble. There are the 8 bits needed to store the pub/pri index!
Fantastic solution Chip! Looking forward to seeing where Spin2 is going.
BTW Is the forum software broken again? I cannot use the reply with quote.
But you must have types in the symbol table for things declared in the OBJ section. Couldn't you just keep track of the types of function/method parameters as well? That way you could pass a reference to an object to a function/method by just passing the VBASE of the object and inferring the PBASE from the type.
Edit: Actually, forget this idea. Object references really aren't that useful unless you also support inheritance and virtual functions and that would complicate Spin too much I think. Sorry for the distraction!
The current compiler-scope limitation is that it's only aware, in detail, of the object you are compiling. The child objects only provide names of PUB's and constants, resulting from their own, separate, compilation.
The current compiler-scope limitation is that it's only aware, in detail, of the object you are compiling. The child objects only provide names of PUB's and constants, resulting from their own, separate, compilation.
But isn't that all you need? If you know that a function parameter is of type "reference to OBJ Foo" then all you need is the table of PUBs and constants for object type "foo" to compile any any expression using that object reference. In other words, if I have something like this in an object definition:
PUB my_function(my_obj_ref as Foo)
my_obj_ref.pub_of_Foo(x, y, z)
Since you know that the parameter named "my_obj_ref" is a reference to an object of type "Foo", you can use that information to properly compile the expression "my_obj_ref.pub_of_Foo" and resolve the "my_pub_of_Foo" symbol to the offset of that function in the method table for objects of type "Foo".
(Ugh, that sentence is probably impossible to parse. I hope you understand what I mean.)
Comments
I still only read this thread.
But have some conclusions -- Why people complain that in P1 it function in other way that in P2 --- It was said from start P2 will not be 100% code compatible.
Now one question to Chip.
For me simple schematic say much more that 1000 words -- so question is:
Can You provide us with simple Block schematic to I/O pins - If possible even to Counters.
That can simplify understanding and give all info to use that parts most effectively.
I must make some block diagrams of these circuits. I will try to get this done soon - particularly the I/O pin diagram, since it's a lot simpler. I've been busy working on the Spin2 interpreter for a while now, and I haven't made any new documentation lately.
About function "mega-pointers": I found a way to fit them into two longs. A function pointer must include a 32-bit pbase and a 32-bit vbase, along with an 8-bit pub/pri index. It turns out that because pbase and vbase are quad-aligned in Spin2, both have %0000 in the bottom nibble. There are the 8 bits needed to store the pub/pri index!
That's all correct, but if you are calling out a method within that object (to make a "mega-pointer"), you need another 8 bits for the method's index value.
That's good. I'm impressed with how well you guys do with your inferences and extrapolations. I'm horrible at understanding how other people do things.
This mega-pointer might seem kind of arbitrary in its purpose and composition, but the key is that it can be compiled with limited scope and resolve final details at run-time. Just a pointer to an object would need a lot more compile-time awareness to make use of.
Edit: Actually, forget this idea. Object references really aren't that useful unless you also support inheritance and virtual functions and that would complicate Spin too much I think. Sorry for the distraction!
Fantastic solution Chip! Looking forward to seeing where Spin2 is going.
BTW Is the forum software broken again? I cannot use the reply with quote.
The current compiler-scope limitation is that it's only aware, in detail, of the object you are compiling. The child objects only provide names of PUB's and constants, resulting from their own, separate, compilation.
Since you know that the parameter named "my_obj_ref" is a reference to an object of type "Foo", you can use that information to properly compile the expression "my_obj_ref.pub_of_Foo" and resolve the "my_pub_of_Foo" symbol to the offset of that function in the method table for objects of type "Foo".
(Ugh, that sentence is probably impossible to parse. I hope you understand what I mean.)