Since lately there a some interest in C/C++ compiling and some people mentioned how it would be cool to make everything to be dynamically compiled, i decided to make a preview announce of a research which i done during last few months.
A project name is a weird, and definitely it require more appropriate name to not scare off a potential users/developers, but this is not an issue right now :)
Let me describe a little the key features of project and what goals it pursuing:
- the main goal is to create a smalltalk language environment (similar to other smalltalks), but i avoid to call it VM, because its not really a VM, because there is no VM at all. - everything is written in smalltalk - system is completely self sustaining: smalltalk code compiled down to native code (no initial need in having bytecodes). Of course no-one prevents you from implementing a bytecode interpreter on top of it. But this is beyond the scope of current project. :) - there is no primitives nor need in writing external code in C (or in any other statically typed language). A primitives replaced by native methods (methods with <native> pragma), by using which you can implement any low-level behavior.
- everything (by a 99.9% ;) in system is up to implementor. There is a few 'glue' semantics used by compiler, but compiler itself extensively using static inlining (inlining native methods from well-known classes such as CompiledMethod/ProtoObject or StackContext). Memory management/relocation, FFI , a diverse set of what we currently know as 'privitives' will be implemented in a system. This opens a potentially huge playground, how system would look like :)
- avoid using global state. All state which code can potentially refer to is placed in literals. There is no difference between native methods and smalltalk methods in compiled method format. The difference only how they are compiled. Of course there will be some global state , i think it would be a single 'lobby' object, which contains a symbols table (required to support symbols uniqueness thoughout all system). But anyway, references to it will be possible only from method literals. - generated native code are location independent. Since all jumps will be relative, and all location-dependent stuff are either held in literals or computed. Therefore a CompiledMethod instances can be relocated freely in memory (by GC and friends) without any change that it will cause any harm.
- compiler translates smalltalk code to a lambda representation. Then using different transformations it generates a low-level lambdas, which represent a virtual machine CPU instructions. No AST nor bunch of different classes to represent semantic elements of code used. Lambdas all the way down.
- an object memory model is initially based on Ian's minimal object system. With some changes.
You can download a snapshot of project at squeaksource: http://www.squeaksource.com/CorruptVM
What is currently should work:
CVMachineSimulator bootstrap -- bootstrap a object memory for simulation CVSimulationTests run -- run different tests on boostrapped object memory
There are also an initial implementation of translating to native code using Exupery (you need to load Exupery for that). Do it: CVExuperyCompiler test inspect
I am currently open for suggestions and advices or discussion in how is better to implement system based on such design. Would be glad to read your comments.
There is also a wiki page of project: http://wiki.squeak.org/squeak/6041
Sounds like a good idea! This reminds me on Forth and its cross compilers and recently factor.
"Igor Stasenko" siguctua@gmail.com Gesendet von: squeak-dev-bounces@lists.squeakfoundation.org 01.07.2008 08:07 Bitte antworten an The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
An "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Kopie
Thema [squeak-dev] [ANN] CorruptVM preview
Since lately there a some interest in C/C++ compiling and some people mentioned how it would be cool to make everything to be dynamically compiled, i decided to make a preview announce of a research which i done during last few months.
A project name is a weird, and definitely it require more appropriate name to not scare off a potential users/developers, but this is not an issue right now :)
Let me describe a little the key features of project and what goals it pursuing:
- the main goal is to create a smalltalk language environment (similar to other smalltalks), but i avoid to call it VM, because its not really a VM, because there is no VM at all. - everything is written in smalltalk - system is completely self sustaining: smalltalk code compiled down to native code (no initial need in having bytecodes). Of course no-one prevents you from implementing a bytecode interpreter on top of it. But this is beyond the scope of current project. :) - there is no primitives nor need in writing external code in C (or in any other statically typed language). A primitives replaced by native methods (methods with <native> pragma), by using which you can implement any low-level behavior.
- everything (by a 99.9% ;) in system is up to implementor. There is a few 'glue' semantics used by compiler, but compiler itself extensively using static inlining (inlining native methods from well-known classes such as CompiledMethod/ProtoObject or StackContext). Memory management/relocation, FFI , a diverse set of what we currently know as 'privitives' will be implemented in a system. This opens a potentially huge playground, how system would look like :)
- avoid using global state. All state which code can potentially refer to is placed in literals. There is no difference between native methods and smalltalk methods in compiled method format. The difference only how they are compiled. Of course there will be some global state , i think it would be a single 'lobby' object, which contains a symbols table (required to support symbols uniqueness thoughout all system). But anyway, references to it will be possible only from method literals. - generated native code are location independent. Since all jumps will be relative, and all location-dependent stuff are either held in literals or computed. Therefore a CompiledMethod instances can be relocated freely in memory (by GC and friends) without any change that it will cause any harm.
- compiler translates smalltalk code to a lambda representation. Then using different transformations it generates a low-level lambdas, which represent a virtual machine CPU instructions. No AST nor bunch of different classes to represent semantic elements of code used. Lambdas all the way down.
- an object memory model is initially based on Ian's minimal object system. With some changes.
You can download a snapshot of project at squeaksource: http://www.squeaksource.com/CorruptVM
What is currently should work:
CVMachineSimulator bootstrap -- bootstrap a object memory for simulation CVSimulationTests run -- run different tests on boostrapped object memory
There are also an initial implementation of translating to native code using Exupery (you need to load Exupery for that). Do it: CVExuperyCompiler test inspect
I am currently open for suggestions and advices or discussion in how is better to implement system based on such design. Would be glad to read your comments.
There is also a wiki page of project: http://wiki.squeak.org/squeak/6041
Hi Igor, this looks cool. It is related to David Ungar's Klein which was an attempt at a self-hosted Self system, and to Exupery and Typed Smalltalk, and Ian's Cola. Whenever I've thought about this style VM I've always been put off by a bug issue. How are you going to deal with hard crashes?
One needs some form of symbolic debugging at the machine code level. If one is debugging the Squeak VM (or any other Smalltalk VM I've worked on) one can compile a version with debug symbols, use the platform's debugger (e.g. gdb) and write debugging functions in C to be called from that debugger.
If one has a self-hosted Smalltalk system with no symbolic information that can be read by a platform's debugger because the system, being Smalltalk, has is own fully reflective self-description, then it seems to me one really is fishing about in a vast hex dump of the entire system, and that doesn't seem workable. Note that in the presence of a hard crash one doesnt have the system to debug itselr because it has just crashed.
So are you going to export symbolic information that a platform debugger can consume (and if so, how?) or are you going to do something else (e.g. mirrors)?
On Mon, Jun 30, 2008 at 11:06 PM, Igor Stasenko siguctua@gmail.com wrote:
Since lately there a some interest in C/C++ compiling and some people mentioned how it would be cool to make everything to be dynamically compiled, i decided to make a preview announce of a research which i done during last few months.
A project name is a weird, and definitely it require more appropriate name to not scare off a potential users/developers, but this is not an issue right now :)
Let me describe a little the key features of project and what goals it pursuing:
- the main goal is to create a smalltalk language environment (similar
to other smalltalks), but i avoid to call it VM, because its not really a VM, because there is no VM at all.
- everything is written in smalltalk
- system is completely self sustaining: smalltalk code compiled down
to native code (no initial need in having bytecodes). Of course no-one prevents you from implementing a bytecode interpreter on top of it. But this is beyond the scope of current project. :)
- there is no primitives nor need in writing external code in C (or in
any other statically typed language). A primitives replaced by native methods (methods with <native> pragma), by using which you can implement any low-level behavior.
- everything (by a 99.9% ;) in system is up to implementor. There is
a few 'glue' semantics used by compiler, but compiler itself extensively using static inlining (inlining native methods from well-known classes such as CompiledMethod/ProtoObject or StackContext). Memory management/relocation, FFI , a diverse set of what we currently know as 'privitives' will be implemented in a system. This opens a potentially huge playground, how system would look like :)
- avoid using global state. All state which code can potentially refer
to is placed in literals. There is no difference between native methods and smalltalk methods in compiled method format. The difference only how they are compiled. Of course there will be some global state , i think it would be a single 'lobby' object, which contains a symbols table (required to support symbols uniqueness thoughout all system). But anyway, references to it will be possible only from method literals.
- generated native code are location independent. Since all jumps will
be relative, and all location-dependent stuff are either held in literals or computed. Therefore a CompiledMethod instances can be relocated freely in memory (by GC and friends) without any change that it will cause any harm.
- compiler translates smalltalk code to a lambda representation. Then
using different transformations it generates a low-level lambdas, which represent a virtual machine CPU instructions. No AST nor bunch of different classes to represent semantic elements of code used. Lambdas all the way down.
- an object memory model is initially based on Ian's minimal object
system. With some changes.
You can download a snapshot of project at squeaksource: http://www.squeaksource.com/CorruptVM
What is currently should work:
CVMachineSimulator bootstrap -- bootstrap a object memory for simulation CVSimulationTests run -- run different tests on boostrapped object memory
There are also an initial implementation of translating to native code using Exupery (you need to load Exupery for that). Do it: CVExuperyCompiler test inspect
I am currently open for suggestions and advices or discussion in how is better to implement system based on such design. Would be glad to read your comments.
There is also a wiki page of project: http://wiki.squeak.org/squeak/6041
-- Best regards, Igor Stasenko AKA sig.
On Tue, Jul 1, 2008 at 2:44 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Igor, this looks cool. It is related to David Ungar's Klein which was an attempt at a self-hosted Self system, and to Exupery and Typed Smalltalk, and Ian's Cola. Whenever I've thought about this style VM I've always been put off by a bug issue. How are you going to deal with hard crashes? One needs some form of symbolic debugging at the machine code level. If one is debugging the Squeak VM (or any other Smalltalk VM I've worked on) one can compile a version with debug symbols, use the platform's debugger (e.g. gdb) and write debugging functions in C to be called from that debugger. If one has a self-hosted Smalltalk system with no symbolic information that can be read by a platform's debugger because the system, being Smalltalk, has is own fully reflective self-description, then it seems to me one really is fishing about in a vast hex dump of the entire system, and that doesn't seem workable.
One way to fix this is to make debuggers work differently. One image should be able to inspect and control another, as in Spoon. In general, the debugger for image X runs in the controller of X, not in X itself. Of course, the compiler should probably be in the controller, as well. This would make a lot of things easier, such as parallelism, security, and fault tolerance.
-Ralph
2008/7/1 Eliot Miranda eliot.miranda@gmail.com:
Hi Igor, this looks cool. It is related to David Ungar's Klein which was an attempt at a self-hosted Self system, and to Exupery and Typed Smalltalk, and Ian's Cola. Whenever I've thought about this style VM I've always been put off by a bug issue. How are you going to deal with hard crashes? One needs some form of symbolic debugging at the machine code level. If one is debugging the Squeak VM (or any other Smalltalk VM I've worked on) one can compile a version with debug symbols, use the platform's debugger (e.g. gdb) and write debugging functions in C to be called from that debugger. If one has a self-hosted Smalltalk system with no symbolic information that can be read by a platform's debugger because the system, being Smalltalk, has is own fully reflective self-description, then it seems to me one really is fishing about in a vast hex dump of the entire system, and that doesn't seem workable. Note that in the presence of a hard crash one doesnt have the system to debug itselr because it has just crashed.
I have some thoughts about using properly set exception handling mechanism. In Windows its a Structured Exception Handling (SEH) , provided by OS, in unixes there is need to set up a signal handlers. So, if properly set up, it is possible to debug most of errors without using external debugger process, and you don't have to generate any symbolic info for them. There are vast possible options and solutions. As Ralph mentioned, it can keep 2 object memories - one for running image, second for controlling it.
So are you going to export symbolic information that a platform debugger can consume (and if so, how?) or are you going to do something else (e.g. mirrors)?
Good question, i need to think about it. I don't think it would be easy to bind such info with platform debugger (because they all are C-centric and its unlikely that they will be able to find any info in freely movable code ;) ), what i think is more realistic, that we can run an image containing debugger, and provide enough interface in running image, so debugger can extract all required info from process being debugged.
On Tue, Jul 1, 2008 at 3:33 PM, Igor Stasenko siguctua@gmail.com wrote:
2008/7/1 Eliot Miranda eliot.miranda@gmail.com:
Hi Igor, this looks cool. It is related to David Ungar's Klein which was an attempt at a self-hosted Self system, and to Exupery and Typed Smalltalk, and Ian's Cola. Whenever I've thought about this style VM I've always
been
put off by a bug issue. How are you going to deal with hard crashes? One needs some form of symbolic debugging at the machine code level. If
one
is debugging the Squeak VM (or any other Smalltalk VM I've worked on) one can compile a version with debug symbols, use the platform's debugger
(e.g.
gdb) and write debugging functions in C to be called from that debugger. If one has a self-hosted Smalltalk system with no symbolic information
that
can be read by a platform's debugger because the system, being Smalltalk, has is own fully reflective self-description, then it seems to me one
really
is fishing about in a vast hex dump of the entire system, and that
doesn't
seem workable. Note that in the presence of a hard crash one doesnt have the system to debug itselr because it has just crashed.
I have some thoughts about using properly set exception handling mechanism. In Windows its a Structured Exception Handling (SEH) , provided by OS, in unixes there is need to set up a signal handlers. So, if properly set up, it is possible to debug most of errors without using external debugger process, and you don't have to generate any symbolic info for them. There are vast possible options and solutions. As Ralph mentioned, it can keep 2 object memories - one for running image, second for controlling it.
So are you going to export symbolic information that a platform debugger
can
consume (and if so, how?) or are you going to do something else (e.g. mirrors)?
Good question, i need to think about it. I don't think it would be easy to bind such info with platform debugger (because they all are C-centric and its unlikely that they will be able to find any info in freely movable code ;) ), what i think is more realistic, that we can run an image containing debugger, and provide enough interface in running image, so debugger can extract all required info from process being debugged.
This is the "mirrors" approach I alluded to. The right approach is to implement the debugger with a mirror between it and the system it looks at. There is a mirror for local debugging taht is fairly transparent. then there is a mirror for the renoter system which is much more involved because it has to use peek and poke to examine the memory space of the target process and it has to extract meta information from it (and in the presence of errors, e.g. the hard crash could have corrupted memory).
Let me encourage you to think about this soon and work on it asap because it is a really important issue. If you don't have a good debugging environment up front your progress will be slow. No one has succeeded in bringing such a system for a Smalltalk-like language into production use yet (neither Klein nor TypedSmalltalk nor Exupery has made it to production use). Making it happen would be fantastic. You have the Spoon system to build upon.
You have to both provide a Smalltalk-level debugger and a machine code debugger which can display machine instructions, registers and memory. It would be nice to be able to reuse disassemblers et al from other components but you might find that Smalltalk implementations are quicker to write and easier to understand and use. But you will need them.
Best Eliot
-- Best regards, Igor Stasenko AKA sig.
2008/7/2 Eliot Miranda eliot.miranda@gmail.com:
This is the "mirrors" approach I alluded to. The right approach is to implement the debugger with a mirror between it and the system it looks at. There is a mirror for local debugging taht is fairly transparent. then there is a mirror for the renoter system which is much more involved because it has to use peek and poke to examine the memory space of the target process and it has to extract meta information from it (and in the presence of errors, e.g. the hard crash could have corrupted memory).
I have some ideas about it. First: nobody prevents me to have image containing separate object memories. Its only a question how to load and bootstrap it :)
Or, more specific: i think i will introduce the island model (or vats) from the start. So there will be a multiple islands (which can be possibly run in parallel native threads), which don't share anything, or sharing a protected memory region, writing to which is guarded by a lot of checks and rules :)
Since there is nothing outside, which dictates me to have: single heap, single GC, single object memory; it is possible to implement a system, which could have different memory regions governed by different memory managers and garbage collectors.
Then debugging looks much less scary than comparing to system crippled by VM written in C :)
Let me encourage you to think about this soon and work on it asap because it is a really important issue. If you don't have a good debugging environment up front your progress will be slow. No one has succeeded in bringing such a system for a Smalltalk-like language into production use yet (neither Klein nor TypedSmalltalk nor Exupery has made it to production use). Making it happen would be fantastic. You have the Spoon system to build upon.
Absolutely, a system without good means of debugging can't progress fast (and its mainly just a useless artifact for serious deployment). I'm concerned that amount of debug information to be added to method would hit hard the memory consumption.
You have to both provide a Smalltalk-level debugger and a machine code debugger which can display machine instructions, registers and memory. It would be nice to be able to reuse disassemblers et al from other components but you might find that Smalltalk implementations are quicker to write and easier to understand and use. But you will need them.
Heh.. right, but it would take ages :) A teamwork is what is needed. I looking for a people who may want to join crusade for the ultimate smalltalk self-sustaining system implementation :)
On Tue, Jul 1, 2008 at 5:05 PM, Igor Stasenko siguctua@gmail.com wrote:
2008/7/2 Eliot Miranda eliot.miranda@gmail.com:
This is the "mirrors" approach I alluded to. The right approach is to implement the debugger with a mirror between it and the system it looks
at.
There is a mirror for local debugging taht is fairly transparent. then there is a mirror for the renoter system which is much more involved
because
it has to use peek and poke to examine the memory space of the target process and it has to extract meta information from it (and in the presence of errors, e.g. the hard crash could have corrupted memory).
I have some ideas about it. First: nobody prevents me to have image containing separate object memories. Its only a question how to load and bootstrap it :)
Or, more specific: i think i will introduce the island model (or vats) from the start. So there will be a multiple islands (which can be possibly run in parallel native threads), which don't share anything, or sharing a protected memory region, writing to which is guarded by a lot of checks and rules :)
Since there is nothing outside, which dictates me to have: single heap, single GC, single object memory; it is possible to implement a system, which could have different memory regions governed by different memory managers and garbage collectors.
This assumes that an error in one island can't corrupt the heap of another island, not a safe assumption. You really need to use separate address spaces for isolation. If the mirrors are done right the tool side of things is the same anyway.
Then debugging looks much less scary than comparing to system crippled
by VM written in C :)
Let me encourage you to think about this soon and work on it asap because
it
is a really important issue. If you don't have a good debugging
environment
up front your progress will be slow. No one has succeeded in bringing
such
a system for a Smalltalk-like language into production use yet (neither Klein nor TypedSmalltalk nor Exupery has made it to production use).
Making
it happen would be fantastic. You have the Spoon system to build upon.
Absolutely, a system without good means of debugging can't progress fast (and its mainly just a useless artifact for serious deployment). I'm concerned that amount of debug information to be added to method would hit hard the memory consumption.
You have to both provide a Smalltalk-level debugger and a machine code debugger which can display machine instructions, registers and memory.
It
would be nice to be able to reuse disassemblers et al from other
components
but you might find that Smalltalk implementations are quicker to write
and
easier to understand and use. But you will need them.
Heh.. right, but it would take ages :) A teamwork is what is needed. I looking for a people who may want to join crusade for the ultimate smalltalk self-sustaining system implementation :)
I hear you. But for me, first things first :)
best Eliot
2008/7/2 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Jul 1, 2008 at 5:05 PM, Igor Stasenko siguctua@gmail.com wrote:
2008/7/2 Eliot Miranda eliot.miranda@gmail.com:
This is the "mirrors" approach I alluded to. The right approach is to implement the debugger with a mirror between it and the system it looks at. There is a mirror for local debugging taht is fairly transparent. then there is a mirror for the renoter system which is much more involved because it has to use peek and poke to examine the memory space of the target process and it has to extract meta information from it (and in the presence of errors, e.g. the hard crash could have corrupted memory).
I have some ideas about it. First: nobody prevents me to have image containing separate object memories. Its only a question how to load and bootstrap it :)
Or, more specific: i think i will introduce the island model (or vats) from the start. So there will be a multiple islands (which can be possibly run in parallel native threads), which don't share anything, or sharing a protected memory region, writing to which is guarded by a lot of checks and rules :)
Since there is nothing outside, which dictates me to have: single heap, single GC, single object memory; it is possible to implement a system, which could have different memory regions governed by different memory managers and garbage collectors.
This assumes that an error in one island can't corrupt the heap of another island, not a safe assumption. You really need to use separate address spaces for isolation. If the mirrors are done right the tool side of things is the same anyway.
Then its coming closer to a point, when without speaking directly with hardware (without being restricted by OS) is the only reliable option. It would be much painless if things could operate on zero ring (kernel mode). But without it.. we have to live in user-mode memory model, provided by OS. And hence, should heed what OS dictates: use separate process to debug another process.
Things are really, can be a lot easier, if it could manage physical memory itself.. For instance, i feel headache each time when i thinking how to make Processes cheap. A straightforward approach is to use separate native thread for each Process instance, and let OS manage the stack. But this is far from cheap. A single native thread reserving at least two/three pages of physical memory for stack. I could make own stack, and use separate stack (not provided by OS by default), and can make own checks for stack space left. But then in case when you do foreign calls, things makes the whole idea not so attractive - foreign functions have no idea how large my stack is, and can't check it in same way is my code does.
So without hard hacking OS internals, the idea of using zeons of Processes scheduled between a limited numbers of native threads is barely possible.
Its shows, how inflexible and rigid operating systems can be, if you want to write in any other language than C :)
Then debugging looks much less scary than comparing to system crippled by VM written in C :)
Let me encourage you to think about this soon and work on it asap because it is a really important issue. If you don't have a good debugging environment up front your progress will be slow. No one has succeeded in bringing such a system for a Smalltalk-like language into production use yet (neither Klein nor TypedSmalltalk nor Exupery has made it to production use). Making it happen would be fantastic. You have the Spoon system to build upon.
Absolutely, a system without good means of debugging can't progress fast (and its mainly just a useless artifact for serious deployment). I'm concerned that amount of debug information to be added to method would hit hard the memory consumption.
You have to both provide a Smalltalk-level debugger and a machine code debugger which can display machine instructions, registers and memory. It would be nice to be able to reuse disassemblers et al from other components but you might find that Smalltalk implementations are quicker to write and easier to understand and use. But you will need them.
Heh.. right, but it would take ages :) A teamwork is what is needed. I looking for a people who may want to join crusade for the ultimate smalltalk self-sustaining system implementation :)
I hear you. But for me, first things first :)
best Eliot
Hi Igor,
On Tue, Jul 1, 2008 at 6:02 PM, Igor Stasenko siguctua@gmail.com wrote:
2008/7/2 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Jul 1, 2008 at 5:05 PM, Igor Stasenko siguctua@gmail.com
wrote:
2008/7/2 Eliot Miranda eliot.miranda@gmail.com:
This is the "mirrors" approach I alluded to. The right approach is to implement the debugger with a mirror between it and the system it
looks
at. There is a mirror for local debugging taht is fairly transparent.
then
there is a mirror for the renoter system which is much more involved because it has to use peek and poke to examine the memory space of the target process and it has to extract meta information from it (and in the presence of errors, e.g. the hard crash could have corrupted memory).
I have some ideas about it. First: nobody prevents me to have image containing separate object memories. Its only a question how to load and bootstrap it :)
Or, more specific: i think i will introduce the island model (or vats) from the start. So there will be a multiple islands (which can be possibly run in parallel native threads), which don't share anything, or sharing a protected memory region, writing to which is guarded by a lot of checks and rules :)
Since there is nothing outside, which dictates me to have: single heap, single GC, single object memory; it is possible to implement a system, which could have different memory regions governed by different memory managers and garbage collectors.
This assumes that an error in one island can't corrupt the heap of
another
island, not a safe assumption. You really need to use separate address spaces for isolation. If the mirrors are done right the tool side of
things
is the same anyway.
Then its coming closer to a point, when without speaking directly with hardware (without being restricted by OS) is the only reliable option. It would be much painless if things could operate on zero ring (kernel mode). But without it.. we have to live in user-mode memory model, provided by OS. And hence, should heed what OS dictates: use separate process to debug another process.
Things are really, can be a lot easier, if it could manage physical memory itself.. For instance, i feel headache each time when i thinking how to make Processes cheap. A straightforward approach is to use separate native thread for each Process instance, and let OS manage the stack. But this is far from cheap. A single native thread reserving at least two/three pages of physical memory for stack. I could make own stack, and use separate stack (not provided by OS by default), and can make own checks for stack space left. But then in case when you do foreign calls, things makes the whole idea not so attractive - foreign functions have no idea how large my stack is, and can't check it in same way is my code does.
A foreign call is a perfect time to do a stack switch. One has to marshall arguments from one language to another so it doesn't add asny overhead to marshall objects one one stack into values passed out on another stack. You pay a little bit extra on the return path where you do have to change stacks, but its not a huge cost (system calls are not that expensive anymore).
If you take this approach (which is taken by the VisualWorks VM for all primitives written in C, everything except a subset of the core language primitives) you can easily manage your own stack. (It is even easy to allocate the small amount of stack you use on the thread's C stack using alloca. :) )
The native Cog will do this. The StackInterpreter Cog (that today executes 325k bytecodes before hitting incomplete simulation code in BitBltSimulator, sob - I wanted to see some pixels) also does this but only interprets in the stack rather than running natively on it.
2008/7/2 Eliot Miranda eliot.miranda@gmail.com:
A foreign call is a perfect time to do a stack switch. One has to marshall arguments from one language to another so it doesn't add asny overhead to marshall objects one one stack into values passed out on another stack. You pay a little bit extra on the return path where you do have to change stacks, but its not a huge cost (system calls are not that expensive anymore).
yeah, yeah, boring stuff just to make two environments live together without much conflicts. However it adds complexity in managing running machine state. And against nature of simplicity and flexibility. But there is not much choices... I just asking myself, why OS designers didn't thought a bit, about enabling user process to provide control on own stack? Why there is no option to provide a buffer for initial stack, when creating new native thread? Or if not a buffer, then at least a reserved address space.
If you take this approach (which is taken by the VisualWorks VM for all primitives written in C, everything except a subset of the core language primitives) you can easily manage your own stack. (It is even easy to allocate the small amount of stack you use on the thread's C stack using alloca. :) )
It seems the only viable way on modern OSes. Since i don't have to care about primitives (they not exists), the only what i should care of is when it does foreign calls. And since foreign calls are up to implementor - it has nothing to do with compiler. Its only a matter of writing a correct callout code and correctly handling return from it an returned value(s), if any.
The native Cog will do this. The StackInterpreter Cog (that today executes 325k bytecodes before hitting incomplete simulation code in BitBltSimulator, sob - I wanted to see some pixels) also does this but only interprets in the stack rather than running natively on it.
squeak-dev@lists.squeakfoundation.org
-
Dietmar Schielke -
Eliot Miranda -
Igor Stasenko -
Ralph Johnson