It's not uncommon to find x86 code padded with a lot of NOPs that weren't in the original source.
Cowardly assembler! ;-)
[NOPs...] Sometimes they're there to pad the execution pipeline, and sometimes it's just because the code generator allocates a whole large enough for the largest form of an instruction to simplify the branch target calculations.
We must be talking about M$oft assemblers here. ;^p)
Yes. This has been pretty characteristic of MS assemblers as far back as I can remember (i.e. about MASM 2.0 - I remember being quite excited when MASM 4.0 came out - '186 and '286 code!).
The real problem is that the solution in general might require N iterations for a piece of code with N branches -- if promoting one of them from short to long causes the next (or, much more problematically, a preceding) one to become long too.
You're such an optimist. O(n) is close to best case for this problem.
This is a weak form of what I suppose one might call an "oscillating constraints" problem. (Hands up anyone who has ever seen [La]TeX get
Hence, stochastic optimization. Even MS uses stochastic optimizers now, even in vb. (didn't want to say that too loud here. ;) )
The usual cause for "padding" in (capable) assemblers (other than for prefetch alignment, as you point out) is due to dynamic linking where the size of call sites isn't known until link time. (On modern systems the
Not only prefetch alignment. I have heard, although I don't know the details that sometimes it's desirable to force a dead cycle in the execution pipeline. I can only guess that this would be to influence the scheduling of the execution units for complex instructions, but I consider myself to be only a "casual observer" with respect to this kind of thing.
In Smalltalk you've also got a bigger problem: for very long methods the range of even unconditional branches might not be enough, at which point
I know this has nothing whatsoever to do with Smalltalk...)
Well, to kind of tie this back into something relevant to Squeak - I know a few people have talked about "new" VM instruction sets. It seems that it might help to think about a VM where all instructions are the same size.
This could simplify code generation (i.e. compiling methods), and possibly improve performance and *reduce* code size (at least in the case of long methods). The anticipated performance improvement would come from forcing aligned fetches more often and potentially simpler instruction decoding.
It's really nice to work with an architecture where all instructions take up one word of memory, take one cyle to execute, and sometimes can cause five or six different useful things to occur during that one cycle. (ok, so I write a lot of DSP code...) The single cycle thing isn't necessarily relevant for Smalltalk, but those "extended" bytecodes are really distasteful to me.
-Dean
On Thu, 1 Aug 2002, Swan, Dean wrote:
The usual cause for "padding" in (capable) assemblers (other than for prefetch alignment, as you point out) is due to dynamic linking where the
Not only prefetch alignment. I have heard, although I don't know the details that sometimes it's desirable to force a dead cycle in the execution pipeline. I can only guess that this would be to influence the scheduling of the execution units for complex instructions, but I consider myself to be only a "casual observer" with respect to this kind of thing.
I'm by no means an expert either but as far as I understand it higher execution unit utilisation on superscalar processors (e.g., PPC) comes from avoiding data dependencies: grouping together insns that have inputs independent of outputs, avoiding adjacent load/store, and respecting latencies (e.g., load-use and moves to/from "special" registers). Introducing NOPs doesn't really help here.
Introducing extra NOPs is more important w.r.t. throughput in the insn fetch buffer (which ranges from 1 to 8 insns wide on PPC) when there's a control dependency (a branch target isn't yet known). In this case (at least on the PPC) introducing NOPs to ensure that branches occur in the last word of the prefetch buffer (and that targets are in the first word) reduces the number of insns fetched (an entire buffer is fetched at once) that are either never executed or that might be cancelled after speculative execution when the branch condition is finally known. This helps maximise the number of fetched insns that are actually executed.
Well, to kind of tie this back into something relevant to Squeak - I know a few people have talked about "new" VM instruction sets. It seems that it might help to think about a VM where all instructions are the same size.
This could simplify code generation (i.e. compiling methods), and possibly improve performance and *reduce* code size (at least in the case of long methods).
Now I think it's you who's being the optimist. ;) I'm sure that increasing the size of the "operand" fields (selector/variable indices) will increase the overall size of code (the "compact" encodings are there precisely to pack the common cases into as few bytes as possible). The only time you'd win are when there are a lot of out-of-range branches (to or around other branches), but my intution tells me you'd have to work hard to concoct a method where branch density was high enough to offset the space you'd lose in other bytecodes from giving up the highly compact encoding that Squeak has at the moment.
The anticipated performance improvement would come from forcing aligned fetches more often
I'm not sure alignment is really an issue, since bytecodes are (by definition ;) a byte wide. (This would only have an impact on bizarre architectures, like certain so-called "supercomputers", that don't have byte-addressable memory at all.) You _would_ gain in reduced memory traffic (avoiding the additional fetches of operand bytes) but the working set size (and so cache pressure) would also increase. The optimal balance between the last two depends entirely on the physical resources (and memory speeds) of each individual machine, and on the behaviour of each particular application, so I think it's hard to predict whether you'd win or lose in general.
and potentially simpler instruction decoding.
Absolutely.
FWIW, all of the Jitters did a pre-pass over the bytecode to convert everthing into a "normal" form (a total of 20 or so "abstract insns", all of which were the same size and had the "opcode" in the same place) and to eliminate the convoluted "conditional jumps over unconditional jumps".
Like you say, this simplified compilation immensely. Whether or not (or on which architectures and under which conditions) it would increase interpreted performance would make for a fascinating experiment.
Markus has been talking about making parse trees be the "portable form" of compiled methods and then using a runtime compiler to convert them into bytecodes (for interpretation) or native code. Experimenting with different formats of bytecode (or "wordcode") would be really easy (and lots of fun) in such a context.
It's really nice to work with an architecture where all instructions take up one word of memory, take one cyle to execute, and sometimes can cause five or six different useful things to occur during that one cycle. (ok, so I write a lot of DSP code...)
I write lots of PPC code, and with its combination of parallel execution and certain insns (like the masking/inserting shifts/rotates, not to mention the tricks you can do having a full range of logical operators on the eight independent condition code registers) that cook you an entire meal in one cycle, the issues are pretty similar.
The single cycle thing isn't necessarily relevant for Smalltalk, but those "extended" bytecodes are really distasteful to me.
I find them distasteful too. I also find the multiple object header formats equally distasteful. OTOH, every little bit counts when trying to minimise the size of the image -- and there a more than a few people putting Squeak to work on severely limited machines.
Ian
The single cycle thing isn't necessarily relevant for Smalltalk, but those "extended" bytecodes are really distasteful to me.
I find them distasteful too. I also find the multiple object header formats equally distasteful. OTOH, every little bit counts when trying to minimise the size of the image -- and there a more than a few people putting Squeak to work on severely limited machines.
Well, bytecodes do have their place, of course ;-).
But it's great to hear you guys finding the whole current mess distasteful...
Fire up those new-age compilers and take us into the new world!
- D
Dan,
Fire up those new-age compilers and take us into the new world!
- D
OTOH, I want to go back to the future to look for an old-age compiler.
The one that generated _the_very_first_Smalltalk_image.
( The image that Adam used to show Eva her (e)toy :-).
Just wondering if that compiler was written in C(obol) or S(nobol).
Don't I wish that it were written in S(lang) so that it could be turned into a plugin ;-)
The 30th Anniversary for Smalltalk is around the corner.
Would you tell us how was _the_very_first_Smalltalk_image created ?
And who did it.
Cheers,
PhiHo.
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Dan Ingalls Sent: Thursday, August 01, 2002 10:38 PM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Progrmaming in Bytecode?
The single cycle thing isn't necessarily relevant for Smalltalk, but those
"extended"
bytecodes are really distasteful to me.
I find them distasteful too. I also find the multiple object header formats equally distasteful. OTOH, every little bit counts when trying
to minimise the size of the image -- and there a more than a few people
putting Squeak to work on severely limited machines.
Well, bytecodes do have their place, of course ;-).
But it's great to hear you guys finding the whole current mess distasteful...
The story about Smalltalk-72 is in "The Early History of Smalltalk" that I wrote for ACM's "History of Programming Languages" in 93. I have a pdf file which I'll put on an FTP server somewhere. Also, Dan wrote a truly great paper a few years after Smalltalk-72 about Smalltalk-76, a little of which I included in the "History". However, you should read this as well. I think it was for POPL 78, and there is probably an online copy somewhere ....
Cheers,
Alan
At 1:21 AM -0400 8/2/02, PhiHo Hoang wrote:
Dan,
Fire up those new-age compilers and take us into the new world!
- D
OTOH, I want to go back to the future to look for an old-age compiler.
The one that generated _the_very_first_Smalltalk_image.
( The image that Adam used to show Eva her (e)toy :-).
Just wondering if that compiler was written in C(obol) or S(nobol).
Don't I wish that it were written in S(lang) so that it could be turned into a plugin ;-)
The 30th Anniversary for Smalltalk is around the corner.
Would you tell us how was _the_very_first_Smalltalk_image created ?
And who did it.
Cheers,
PhiHo.
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Dan Ingalls Sent: Thursday, August 01, 2002 10:38 PM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Progrmaming in Bytecode?
The single cycle thing isn't necessarily relevant for Smalltalk, but those
"extended"
bytecodes are really distasteful to me.
I find them distasteful too. I also find the multiple object header formats equally distasteful. OTOH, every little bit counts when trying
to minimise the size of the image -- and there a more than a few people
putting Squeak to work on severely limited machines.
Well, bytecodes do have their place, of course ;-).
But it's great to hear you guys finding the whole current mess distasteful...
--
Alan Kay wrote:
The story about Smalltalk-72 is in "The Early History of Smalltalk" that I wrote for ACM's "History of Programming Languages" in 93. I have a pdf file which I'll put on an FTP server somewhere. Also, Dan wrote a truly great paper a few years after Smalltalk-72 about Smalltalk-76, a little of which I included in the "History". However, you should read this as well. I think it was for POPL 78, and there is probably an online copy somewhere ....
http://users.ipa.net/~dwighth/smalltalk/St76/Smalltalk76ProgrammingSystem.ht...
Hi Alan,
Thanks for the info. Frankly (and shame on me), I have not read the papers you mentioned.
Please post a pointer when you have it. Maybe many others did not have a chance to read them either.
It would be fun to look at the first VM, the first compiler and the first image.
I guess they all fit on a floppy (180KB ;-)
Cheers,
PhiHo.
----- Original Message ----- From: "Alan Kay" Alan.Kay@squeakland.org To: squeak-dev@lists.squeakfoundation.org Sent: Friday, August 02, 2002 9:52 AM Subject: RE: Progrmaming in Bytecode?
The story about Smalltalk-72 is in "The Early History of Smalltalk" that I wrote for ACM's "History of Programming Languages" in 93. I have a pdf file which I'll put on an FTP server somewhere. Also, Dan wrote a truly great paper a few years after Smalltalk-72 about Smalltalk-76, a little of which I included in the "History". However, you should read this as well. I think it was for POPL 78, and there is probably an online copy somewhere ....
Cheers,
Alan
At 1:21 AM -0400 8/2/02, PhiHo Hoang wrote:
Dan,
Fire up those new-age compilers and take us into the new world!
- D
OTOH, I want to go back to the future to look for an old-age compiler.
The one that generated _the_very_first_Smalltalk_image.
( The image that Adam used to show Eva her (e)toy :-).
Just wondering if that compiler was written in C(obol) or S(nobol).
Don't I wish that it were written in S(lang) so that it could be turned into a plugin ;-)
The 30th Anniversary for Smalltalk is around the corner.
Would you tell us how was _the_very_first_Smalltalk_image created ?
And who did it.
Cheers,
PhiHo.
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Dan Ingalls Sent: Thursday, August 01, 2002 10:38 PM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Progrmaming in Bytecode?
The single cycle thing isn't necessarily relevant for Smalltalk, but those
"extended"
bytecodes are really distasteful to me.
I find them distasteful too. I also find the multiple object header formats equally distasteful. OTOH, every little bit counts when trying
to minimise the size of the image -- and there a more than a few people
putting Squeak to work on severely limited machines.
Well, bytecodes do have their place, of course ;-).
But it's great to hear you guys finding the whole current mess distasteful...
--
On Fri, Aug 02, 2002 at 10:18:52AM -0400, PhiHo Hoang wrote:
Hi Alan,
Thanks for the info. Frankly (and shame on me), I have not read thepapers you mentioned.
Please post a pointer when you have it. Maybe many others did not have achance to read them either.
It would be fun to look at the first VM, the first compiler and thefirst image.
It's allready there: http://minnow.cc.gatech.edu/squeak/989
"Dan Ingalls did an emulation of the Smalltalk-72 emulator for Alan Kay's birthday. You can find it at ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/goodies/Smalltalk-72/. " Other interesting stuff:
The Smalltalk-72 Instruction Manual (March 76) http://www.spies.com/~aek/pdf/xerox/alto/Smalltalk72_Manual.pdf
The Early History of Smalltalk Tttp://www.metaobject.com/papers/SmallHistory.pdf
Jerry Bell scanned the the original "Personal Dynamic Media" report: http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-April/012060.htm...
download at: http://67.32.22.226/pdm.pdf
Marcus
Hi Marcus,
Thanks for the pointers.
Shouldn't we have a page for all these nice things at SqueakFoundation ?
Cheers,
PhiHo.
----- Original Message ----- From: "Marcus Denker" marcus@ira.uka.de To: squeak-dev@lists.squeakfoundation.org Sent: Friday, August 02, 2002 10:57 AM Subject: Re: Progrmaming in Bytecode?
On Fri, Aug 02, 2002 at 10:18:52AM -0400, PhiHo Hoang wrote:
Hi Alan,
Thanks for the info. Frankly (and shame on me), I have not read thepapers you mentioned.
Please post a pointer when you have it. Maybe many others did not
have a
chance to read them either.
It would be fun to look at the first VM, the first compiler and thefirst image.
It's allready there: http://minnow.cc.gatech.edu/squeak/989
"Dan Ingalls did an emulation of the Smalltalk-72 emulator for Alan Kay's birthday. You can find it at
ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/goodies/Smalltalk-72/.
" Other interesting stuff:
The Smalltalk-72 Instruction Manual (March 76) http://www.spies.com/~aek/pdf/xerox/alto/Smalltalk72_Manual.pdf
The Early History of Smalltalk Tttp://www.metaobject.com/papers/SmallHistory.pdf
Jerry Bell scanned the the original "Personal Dynamic Media" report:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-April/012060.htm l
download at: http://67.32.22.226/pdm.pdf
Marcus-- Marcus Denker marcus@ira.uka.de -- Squeak! http://squeakland.org
Thanks Marcus!
I didn't realize that all these were already out and available!
Cheers,
Alan
------
At 4:57 PM +0200 8/2/02, Marcus Denker wrote:
On Fri, Aug 02, 2002 at 10:18:52AM -0400, PhiHo Hoang wrote:
Hi Alan,
Thanks for the info. Frankly (and shame on me), I have not read thepapers you mentioned.
Please post a pointer when you have it. Maybe many others did not have achance to read them either.
It would be fun to look at the first VM, the first compiler and thefirst image.
It's allready there: http://minnow.cc.gatech.edu/squeak/989
"Dan Ingalls did an emulation of the Smalltalk-72 emulator for Alan Kay's birthday. You can find it at ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/goodies/Smalltalk-72/. " Other interesting stuff:
The Smalltalk-72 Instruction Manual (March 76) http://www.spies.com/~aek/pdf/xerox/alto/Smalltalk72_Manual.pdf
The Early History of Smalltalk Tttp://www.metaobject.com/papers/SmallHistory.pdf
Jerry Bell scanned the the original "Personal Dynamic Media" report: http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-April/012060.htm...
download at: http://67.32.22.226/pdm.pdf
Marcus-- Marcus Denker marcus@ira.uka.de -- Squeak! http://squeakland.org
--
Also, Dan a few year ago for fun did an emulation of the Alto in Squeak that would run Smalltalk-72. The original "blue book" that contained the ST-72 system bootstrap is quite fun to read.
Cheers,
Alan
-----
At 10:18 AM -0400 8/2/02, PhiHo Hoang wrote:
Hi Alan,
Thanks for the info. Frankly (and shame on me), I have not read thepapers you mentioned.
Please post a pointer when you have it. Maybe many others did not have achance to read them either.
It would be fun to look at the first VM, the first compiler and thefirst image.
I guess they all fit on a floppy (180KB ;-) Cheers, PhiHo.----- Original Message ----- From: "Alan Kay" Alan.Kay@squeakland.org To: squeak-dev@lists.squeakfoundation.org Sent: Friday, August 02, 2002 9:52 AM Subject: RE: Progrmaming in Bytecode?
The story about Smalltalk-72 is in "The Early History of Smalltalk" that I wrote for ACM's "History of Programming Languages" in 93. I have a pdf file which I'll put on an FTP server somewhere. Also, Dan wrote a truly great paper a few years after Smalltalk-72 about Smalltalk-76, a little of which I included in the "History". However, you should read this as well. I think it was for POPL 78, and there is probably an online copy somewhere ....
Cheers,
Alan
At 1:21 AM -0400 8/2/02, PhiHo Hoang wrote:
Dan,
Fire up those new-age compilers and take us into the new world!
- D
OTOH, I want to go back to the future to look for an old-age compiler.
The one that generated _the_very_first_Smalltalk_image.
( The image that Adam used to show Eva her (e)toy :-).
Just wondering if that compiler was written in C(obol) or S(nobol).
Don't I wish that it were written in S(lang) so that it could be turned into a plugin ;-)
The 30th Anniversary for Smalltalk is around the corner.
Would you tell us how was _the_very_first_Smalltalk_image created ?
And who did it.
Cheers,
PhiHo.
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Dan Ingalls Sent: Thursday, August 01, 2002 10:38 PM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Progrmaming in Bytecode?
The single cycle thing isn't necessarily relevant for Smalltalk, but those
"extended"
bytecodes are really distasteful to me.
I find them distasteful too. I also find the multiple object header formats equally distasteful. OTOH, every little bit counts when trying
to minimise the size of the image -- and there a more than a few people
putting Squeak to work on severely limited machines.
Well, bytecodes do have their place, of course ;-).
But it's great to hear you guys finding the whole current mess distasteful...
--
--
Also, Dan a few year ago for fun did an emulation of the Alto in Squeak that would run Smalltalk-72. The original "blue book" that contained the ST-72 system bootstrap is quite fun to read.
It's actually an emulation of the ST-72 interpreter for that ALTO, not the ALTO in general (thought about it, but someone else was already doing that, and I wasn't as interested).
As Marcus points out, you can find it at
ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/goodies/Smalltalk-72/
I'll try, in the next little while, to package it all up as a project that can be loaded into a vanilla Squeak, so it's easier for people to play with.
About ST-76, the entire paper is available on line at
http://users.ipa.net/~dwighth/smalltalk/St76/ Smalltalk76ProgrammingSystem.html
(sorry, you'll have to glue those two lines together), thanks to a lot of careful work by Dwight Hughes.
And Speaking of ST-76, Helge Horch and I have been playing off and on with a Squeak reconstruction of that system (I have the bootstrap for it, too). Maybe now is the time to get it actually running. There are a number of approaches which I can go into if there's more interest.
- Dan
Thanks Dan!
Both of these are quite interesting in their own very different ways ....
Cheers,
Alan
------
At 9:25 AM -0700 8/2/02, Dan Ingalls wrote:
Also, Dan a few year ago for fun did an emulation of the Alto in
Squeak that would run Smalltalk-72. The original "blue book" that contained the ST-72 system bootstrap is quite fun to read.
It's actually an emulation of the ST-72 interpreter for that ALTO, not the ALTO in general (thought about it, but someone else was already doing that, and I wasn't as interested).
As Marcus points out, you can find it at
ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/goodies/Smalltalk-72/
I'll try, in the next little while, to package it all up as a project that can be loaded into a vanilla Squeak, so it's easier for people to play with.
About ST-76, the entire paper is available on line at
http://users.ipa.net/~dwighth/smalltalk/St76/ Smalltalk76ProgrammingSystem.html
(sorry, you'll have to glue those two lines together), thanks to a lot of careful work by Dwight Hughes.
And Speaking of ST-76, Helge Horch and I have been playing off and on with a Squeak reconstruction of that system (I have the bootstrap for it, too). Maybe now is the time to get it actually running. There are a number of approaches which I can go into if there's more interest.
- Dan
--
Hi Dan,
I am interested in all you have about ST-76. Perhaps I can help ?
I have tried to implement ST-76 based on your paper: - For the interpreter, I used the code of your paper. - For the bootstrap and the kernel I was inspired by the ObjVlisp model. - The primitive are based on the blue book implementation. - For the compiler, I am trying to follow the way of "Monadic Parser Combinators".
I am only working a few hour a week on this, and I still need some month to have a minimal workable prototype.
Have a nice day. Alain
About ST-76, the entire paper is available on line at
http://users.ipa.net/~dwighth/smalltalk/St76/ Smalltalk76ProgrammingSystem.html
(sorry, you'll have to glue those two lines together), thanks to a lot of careful work by Dwight Hughes.
And Speaking of ST-76, Helge Horch and I have been playing off and on with a Squeak reconstruction of that system (I have the bootstrap for it, too). Maybe now is the time to get it actually running. There are a number of approaches which I can go into if there's more interest.
The first real application I ever wrote in Smalltalk was an assembler for the Transputer. It has a nice bytecode-like machine language and the variable sized problem was even worse than in Smalltalk since you have to add prefix instructions for every 4 bits of your operands.
It so happened that I had gone back to the university and the lab was really happy to have me since I was the one who had gotten them into Unix many years before. Now I wanted them to forget Unix and go with Smalltalk instead, so I needed to impress them.
An assembler like this is trivial to write (even in C) so I made it an "instant assembler". You typed your code on the right half of what looks like an output listing. In the left half you saw the hex machine code and it was updated as you typed in the code! Take that, you nasty C. This meant that when you added an instruction, any number of jumps might suddenly become too short. So they would be extended with prefix instructions and that might make other jumps too short. Deleting a line might allow some jumps to become shorter.
We are talking about recalculating all offsets in a fraction of a second on a 4.77 MHz 8086 machine (Smalltalk V). And the Transputer code was far larger than any Smalltalk method should ever be. Sad to say, that lab is still a Unix shop.
On Thursday 01 August 2002 22:49, Ian Piumarta wrote:
On Thu, 1 Aug 2002, Swan, Dean wrote:
and potentially simpler instruction decoding.
Absolutely.
FWIW, all of the Jitters did a pre-pass over the bytecode to convert everthing into a "normal" form (a total of 20 or so "abstract insns", all of which were the same size and had the "opcode" in the same place) and to eliminate the convoluted "conditional jumps over unconditional jumps".
It is interesting how close your SAM instructions are to the current bytecodes in Self (which are different from the ones described in the various papers).
Like you say, this simplified compilation immensely. Whether or not (or on which architectures and under which conditions) it would increase interpreted performance would make for a fascinating experiment.
Some people might want to look at the instruction set I am using on a 16 bit machine (unfortunately too small for Squeak. I would handle something like Little Smalltalk just fine, on the other hand):
http://www.merlintec.com:8080/hardware/Oliver/
The send instructions are hard to understand unless you know that I use full Selector Table Indexing for message dispatch. This was never supposed to be used in practice since the table is only 5% filled, but I have 8MB of RAM (couldn't find a smaller chip to buy) on a 16 bit machine so I could afford it, and it did make the send instructions take only one clock. Returns take two - I could do better but ran out of space on the FPGA.
Markus has been talking about making parse trees be the "portable form" of compiled methods and then using a runtime compiler to convert them into bytecodes (for interpretation) or native code. Experimenting with different formats of bytecode (or "wordcode") would be really easy (and lots of fun) in such a context.
How about my 1984 design for a Smalltalk VM?
http://www.lsi.usp.br/~jecel/st84.txt
-- Jecel
I remember smalltalk well relating to the z80. Old days. Instant assembler (john blatner). TRS 80 mod 1 in a kit. don't know if it was the same. Jerry
squeak-dev@lists.squeakfoundation.org
-
Alain Fischer -
Alan Kay -
Dan Ingalls -
Ian Piumarta -
Jecel Assumpcao Jr -
Jerry Odom -
Joern Eyrich -
Marcus Denker -
PhiHo Hoang -
Swan, Dean