Hello all,
I apologize if this has been asked before (and no doubt it has at some
point, I just couldn't find it). I am interested in experimenting
with creating a VM for Smalltalk (or maybe a hybrid Smalltalk :), but
I wish to use a high level language for this. I wont do it if I have
to use C/C++. Partly because I don't want to make any more projects
in these languages and partly because I want the full power I can get
from the CPU (e.g. catch integer overflow).
Now I'm sure I could use Lisp to do this, but the problem I think I
would have using regular common lisp is that it will include GC code
etc. Of course programming with a GC makes things easier, but it
seems like a bad idea to implement a VM with generational GC etc. with
a language that has it's own GC already.
For those of you who would try to convince me that this isn't a
problem, I appreciate your efforts in saving me time, but I really
think this is a space that needs to be filled. That is, there should
be a high level'ish language that one can build low level things like
OS'es, VM'es etc. in. I know we all want to say "premature
optimization" and various other, correct statements about this, but in
my opinion as long as it remains this way people will always be tied
to C/C++.
Thanks in advance for any pointers anyone could provide, as I suspect
there are such things out there and I just haven't had success finding
them.
Sincerely,
Jason
> I wish to use a high level language for this. I wont do it if I have
> to use C/C++. Partly because I don't want to make any more projects
>
> Now I'm sure I could use Lisp to do this, but the problem I think I
> would have using regular common lisp is that it will include GC code
Maybe an intermediate step is to make an preprocessor that takes a
light lisp syntax and translates that into C.Such a tool could
condense something like linux source code alot, but without changing
the compiled result too much.
Clisp for example uses *.d files, but why havn't they gone one step
further ?
On Jun 19, 9:55 am, ··········@hotmail.com wrote:
> > I wish to use a high level language for this. I wont do it if I have
> > to use C/C++. Partly because I don't want to make any more projects
>
> > Now I'm sure I could use Lisp to do this, but the problem I think I
> > would have using regular common lisp is that it will include GC code
>
> Maybe an intermediate step is to make an preprocessor that takes a
> light lisp syntax and translates that into C.Such a tool could
> condense something like linux source code alot, but without changing
> the compiled result too much.
> Clisp for example uses *.d files, but why havn't they gone one step
> further ?
Thanks for your response. This is, however, exactly what I don't
want. :) I currently do my Smalltalk work in Squeak which was
written by creating a Smalltalk-looking language called Slang that
just translates directly to C. I want to avoid the limitations of C
completely.
It would be nice, for example, to use the GCC framework to just build
an AST and pass it to the GCC back end to generate the machine code
but the problem is that that system assumes a C language so no matter
how you generate your AST you are constrained by what C can do.
On Jun 19, 8:23 am, Jason <··········@hotmail.com> wrote:
> Hello all,
>
> I apologize if this has been asked before (and no doubt it has at some
> point, I just couldn't find it). I am interested in experimenting
> with creating a VM for Smalltalk (or maybe a hybrid Smalltalk :), but
> I wish to use a high level language for this. I wont do it if I have
> to use C/C++. Partly because I don't want to make any more projects
> in these languages and partly because I want the full power I can get
> from the CPU (e.g. catch integer overflow).
>
> Now I'm sure I could use Lisp to do this, but the problem I think I
> would have using regular common lisp is that it will include GC code
> etc. Of course programming with a GC makes things easier, but it
> seems like a bad idea to implement a VM with generational GC etc. with
> a language that has it's own GC already.
>
> For those of you who would try to convince me that this isn't a
> problem, I appreciate your efforts in saving me time, but I really
> think this is a space that needs to be filled. That is, there should
> be a high level'ish language that one can build low level things like
> OS'es, VM'es etc. in. I know we all want to say "premature
> optimization" and various other, correct statements about this, but in
> my opinion as long as it remains this way people will always be tied
> to C/C++.
>
> Thanks in advance for any pointers anyone could provide, as I suspect
> there are such things out there and I just haven't had success finding
> them.
>
> Sincerely,
> Jason
Yeah, I think so too, but...
I have this project where I am designing and implementing a
microprocessor. All design is verified through a simulation which I
wrote in Common Lisp. Because of this, I can implement whatever
instruction set I want.
By having this possibility, I have already been thinking for quite
some months how feasible it would be to implement a C compiler or a
Lisp system on the ISA, and what things could be done to the
instruction set to help in this regard.
There can be much found in a whole lot of sources :
- Computer Architecture : A Quantitative Approach (Patterson,
Hennessy)
- Computer Organization and Design: The Hardware/Software Interface
(Patterson, Hennessy)
- Information about Lisp Machines (Wikipedia)
- Information about the Master Control Program on the B5000, which was
written in a high-level language
- Movitz
Thinking about the issues, I see two problems :
1. Spanning the gap between assembler and your not-C high-level
language.
2. Implementing a core library which can be used to communicate
between your high-level language and your processor.
If you read the first two books in the list, then you will understand
why C (don't know about C++) is used for these tasks. There is a body
of knowledge about porting and building optimising C compilers for
modern microprocessors that is huge. This does not exist for other
languages. Which means that for point 1, any other language that you
use will not be able to take advantage of the things that C compilers
can take advantage (except for the GNU compilers maybe, I do not know,
whould it be possible to use GNAT to write an OS ?).
The core library of point 2) should be written in assembler, and
should only take into account the things needed for low-level access
to the system and return structures which can be used and manipulated
immediately by the supposed HL language, or do things through the
library calls, which do not even have an equivalent in a HLL, like
switching between CPU access levels (user/supervisor).
Think about this bootstrapping part. It is very difficult and
architecture dependent. Of course, what Linus could do with C, someone
else might do with another language. However, C was already well
established, and if you know the structure of your object files, then
it is relatively easy to manipulate them into a binary image, which
you can supply to your computer's boot loader and take control of the
hardware. I think that this is the most difficult part in other
languages, to be able to generate object files which do not have any
other dependencies.
Is it possible in CL to generate a new system with features removed or
changed like you can in FORTH ? I suppose that this should mean that
certain key sources would be written and interpreted in Common Lisp. I
know that SBCL e.g. has parts written in assembler. Would it not be
better for the sake of portability if this where done in a platform
neutral way, and write per architecture an assembler for this code in
Lisp ?
I do not think I have answered your questions per se, but I hope I can
give you an insight into why things are now as they are, and some
possible directions to look into.
Regards,
Jurgen
On Jun 19, 1:08 pm, jurgen_defurne <··············@pandora.be> wrote:
> On Jun 19, 8:23 am, Jason <··········@hotmail.com> wrote:
>
> Yeah, I think so too, but...
>
> I have this project where I am designing and implementing a
> microprocessor. All design is verified through a simulation which I
> wrote in Common Lisp. Because of this, I can implement whatever
> instruction set I want.
>
> By having this possibility, I have already been thinking for quite
> some months how feasible it would be to implement a C compiler or a
> Lisp system on the ISA, and what things could be done to the
> instruction set to help in this regard.
>
> There can be much found in a whole lot of sources :
>
> - Computer Architecture : A Quantitative Approach (Patterson,
> Hennessy)
> - Computer Organization and Design: The Hardware/Software Interface
> (Patterson, Hennessy)
> - Information about Lisp Machines (Wikipedia)
> - Information about the Master Control Program on the B5000, which was
> written in a high-level language
> - Movitz
Cool, thanks for the pointers.
> Thinking about the issues, I see two problems :
>
> 1. Spanning the gap between assembler and your not-C high-level
> language.
Yes, you're right. This is why I was hoping someone had tackled this
already. :)
> 2. Implementing a core library which can be used to communicate
> between your high-level language and your processor.
I had hoped that the "high level, yet low level" language would be
suitable for writing all the code. I guess what I had in mind what
just Lisp syntax (because I think it's the simplest you can have) and
Lisp macros. So the primitives of the language may be quite low
level, but using macros perhaps one could build a useful language out
of it while still having the full flexibility.
> If you read the first two books in the list, then you will understand
> why C (don't know about C++) is used for these tasks. There is a body
> of knowledge about porting and building optimising C compilers for
> modern microprocessors that is huge. This does not exist for other
> languages. Which means that for point 1, any other language that you
> use will not be able to take advantage of the things that C compilers
> can take advantage (except for the GNU compilers maybe, I do not know,
> whould it be possible to use GNAT to write an OS ?).
This is certainly true, but unless someone not smart enough to know
better tries to tackle this we will still be in this situation 100
years from now (unless of course something comes along and makes all
this obsolete). :)
> The core library of point 2) should be written in assembler, and
> should only take into account the things needed for low-level access
> to the system and return structures which can be used and manipulated
> immediately by the supposed HL language, or do things through the
> library calls, which do not even have an equivalent in a HLL, like
> switching between CPU access levels (user/supervisor).
I think my term "high level language" might be a bit misleading here.
I anticipate the language actually being quite low level, but instead
of the awful C syntax (difference between statement and expression,
etc.) it would behave more like Lisp. I.e. mostly written in itself,
powerful macros, etc.
<snip>
> I do not think I have answered your questions per se, but I hope I can
> give you an insight into why things are now as they are, and some
> possible directions to look into.
>
> Regards,
>
> Jurgen
I appreciate your answers.
Jason <··········@hotmail.com> writes:
> I think my term "high level language" might be a bit misleading here.
> I anticipate the language actually being quite low level, but instead
> of the awful C syntax (difference between statement and expression,
> etc.) it would behave more like Lisp. I.e. mostly written in itself,
> powerful macros, etc.
Have a look at:
- prescheme
- bitc http://www.bitc-lang.org/
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On Jun 19, 6:13 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> Jason <··········@hotmail.com> writes:
> > I think my term "high level language" might be a bit misleading here.
> > I anticipate the language actually being quite low level, but instead
> > of the awful C syntax (difference between statement and expression,
> > etc.) it would behave more like Lisp. I.e. mostly written in itself,
> > powerful macros, etc.
>
> Have a look at:
>
> - prescheme
> - bitc http://www.bitc-lang.org/
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> NOTE: The most fundamental particles in this product are held
> together by a "gluing" force about which little is currently known
> and whose adhesive power can therefore not be permanently
> guaranteed.
Cool, thanks for the links. These are the kinds of things I was
looking for. Unfortunately these two still compile to C. There is
also a slimmed down Smalltalk implementation called "Slang" out there
as well.
Jason <··········@hotmail.com> writes:
> On Jun 19, 6:13 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>> Jason <··········@hotmail.com> writes:
>> > I think my term "high level language" might be a bit misleading here.
>> > I anticipate the language actually being quite low level, but instead
>> > of the awful C syntax (difference between statement and expression,
>> > etc.) it would behave more like Lisp. I.e. mostly written in itself,
>> > powerful macros, etc.
>>
>> Have a look at:
>>
>> - prescheme
>> - bitc http://www.bitc-lang.org/
>>
> Cool, thanks for the links. These are the kinds of things I was
> looking for. Unfortunately these two still compile to C. There is
> also a slimmed down Smalltalk implementation called "Slang" out there
> as well.
prescheme and bitc are not implementations. They are programming
language. If you want to compile bitc to Common Lisp or to ix86, you
can easily write a compiler.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Jason wrote:
> with creating a VM for Smalltalk (or maybe a hybrid Smalltalk :), but
> I wish to use a high level language for this. I wont do it if I have
> to use C/C++. Partly because I don't want to make any more projects
> in these languages and partly because I want the full power I can get
> from the CPU (e.g. catch integer overflow).
On a much smaller scale, I wrote a tiny stack based VM in Lisp after
an initial attempt in C++ had become unwieldy very quickly. I found
Lisp to be a pleasant way to write such a program although I didn't
try to circumvent the GC!
I guess there are always ways to keep objects away from the collector
but I don't think that's what you're asking. Maybe the cross-
compilation route is the best option although it sounds like a lot of
tedious work.
Phil
> Now I'm sure I could use Lisp to do this, but the problem I think I
> would have using regular common lisp is that it will include GC code
> etc. Of course programming with a GC makes things easier, but it
> seems like a bad idea to implement a VM with generational GC etc. with
> a language that has it's own GC already.
You can probably have the "Lisp world" and the "VM world" living
concurrently if you're careful. Just grab a chunk of virtual address
space from the OS, and manage it with your GC. The Lisp GC will
(should) happily stick to its own heap, and your GC can do whatever it
wants with its heap. This should be quite efficient, since the Lisp GC
will basically only be cleaning up after the VM itself.
On Jun 19, 4:35 pm, Rayiner Hashem <·······@gmail.com> wrote:
> > Now I'm sure I could use Lisp to do this, but the problem I think I
> > would have using regular common lisp is that it will include GC code
> > etc. Of course programming with a GC makes things easier, but it
> > seems like a bad idea to implement a VM with generational GC etc. with
> > a language that has it's own GC already.
>
> You can probably have the "Lisp world" and the "VM world" living
> concurrently if you're careful. Just grab a chunk of virtual address
> space from the OS, and manage it with your GC. The Lisp GC will
> (should) happily stick to its own heap, and your GC can do whatever it
> wants with its heap. This should be quite efficient, since the Lisp GC
> will basically only be cleaning up after the VM itself.
But I don't think this would be acceptable in e.g. a real-time or soft
real-time world. All the work I might put into making my GC as fast
as possible, as low memory foot-print as possible etc. etc. will not
gain anything if the Lisp GC causes pauses.
> But I don't think this would be acceptable in e.g. a real-time or soft
> real-time world. All the work I might put into making my GC as fast
> as possible, as low memory foot-print as possible etc. etc. will not
> gain anything if the Lisp GC causes pauses.
It should be quite satisfactory for a soft real-time world (if your
VM's GC is up to the task, of course). What you have to keep in mind
is that GC's are generally allocation driven. This means that if your
VM isn't actively allocating memory, the Lisp GC won't be doing
anything. And if your VM is actively allocating memory in time-
critical bits of code, you've lost real-time behavior, Lisp GC or no.
Obviously this depends on the implementation. I can imagine an
implementation having a GC that would randomly cut in just for kicks,
but there is no reason it has to.
On Jun 19, 7:06 pm, Rayiner Hashem <·······@gmail.com> wrote:
> Obviously this depends on the implementation. I can imagine an
> implementation having a GC that would randomly cut in just for kicks,
> but there is no reason it has to.
Well, ok. If there is an implementation that behaves as you describe
and runs on all platforms then I might consider it.
But what I had really expected of the language was something like this
(psuedo-code):
(setf *function-call-setup* (function mySetupFunction))
(def mySetupFunction (ref1 function-address)
(cpu-op 'move 'register-1 ref1)
(cpu-op 'move 'return-register (current-ip + 1))
(cpu-op 'jump function-address)
(cpu-op 'nop)) ; Just so the current-ip + 1 is still inside
this function
I don't know how clear this is, but in other words, I could have
something like this where the strategy is just that each variable
reference (pointer) gets put directly in a register, and then jump to
the new function. deffunction, the macro that creates functions will
use *function-call-setup* to set the function up for calling. If I
later decide that a variation of the C style (pushing the arguments
onto the stack) would be better then I just have to create a new setup
function (or macro) that does the new setup and rebind *function-call-
setup*.
Also, I tried to demonstrate in the above that the assembler
instructions should be as generic as possible without losing the
power, so that the compiler can build the right thing for different
architectures.
> Well, ok. If there is an implementation that behaves as you describe
> and runs on all platforms then I might consider it.
I can't think of any Lisp GC's that *aren't* allocation driven.
>
> But what I had really expected of the language was something like this
> (psuedo-code):
There is no particular reason you can't do this, but recall that
making a compiler that doesn't itself cons a lot is not easy (in C or
Lisp, really). So if you do anything that requires the compiler to
kick in at unexpected times, you're going to have problems with real-
time behavior, no matter what language you implement your VM in.
> Also, I tried to demonstrate in the above that the assembler
> instructions should be as generic as possible without losing the
> power, so that the compiler can build the right thing for different
> architectures.
This is is probably harder than you'd think. Differences in calling
conventions, condition-code handling, operand size, etc, becomes hairy
real fast.
On 2007-06-19, Jason <··········@hotmail.com> wrote:
> Now I'm sure I could use Lisp to do this, but the problem I think I
> would have using regular common lisp is that it will include GC code
> etc. Of course programming with a GC makes things easier, but it
> seems like a bad idea to implement a VM with generational GC etc. with
> a language that has it's own GC already.
I would just use Lisp objects to implement the objects of the VM being
implemented. Re-use the Lisp's GC instead of implementing your own.
> Thanks in advance for any pointers anyone could provide, as I suspect
> there are such things out there and I just haven't had success finding
> them.
Start using DEFSTRUCT for your objects.
Then if the overhead of your implementation's class definition scheme
turns out to be too large, there is probably room for optimization using
implementation-dependent machinery.
For example, in SBCL I create my own LAYOUTs to avoid setting up actual
class definitions while still creating different kinds of instances, and
I subclass LAYOUT to install extra information about those classes,
including a vtable for method dispatch.
On Jun 19, 2:38 pm, David Lichteblau <···········@lichteblau.com>
wrote:
> On 2007-06-19, Jason <··········@hotmail.com> wrote:
>
> > Now I'm sure I could use Lisp to do this, but the problem I think I
> > would have using regular common lisp is that it will include GC code
> > etc. Of course programming with a GC makes things easier, but it
> > seems like a bad idea to implement a VM with generational GC etc. with
> > a language that has it's own GC already.
>
> I would just use Lisp objects to implement the objects of the VM being
> implemented. Re-use the Lisp's GC instead of implementing your own.
I appreciate your effort to save me time, but I'm not trying to get
this implemented as fast as possible. :) I don't *want* Lisp's GC.
It's not optimized for my language, and if a new advance comes along I
either have to wait for the creator of the Lisp implementation I am
using to switch to it, or hack on the Lisp Compiler/whatever myself,
which will likely be in C that I'm trying to avoid. :)
On 2007-06-19, Jason <··········@hotmail.com> wrote:
> I appreciate your effort to save me time, but I'm not trying to get
> this implemented as fast as possible. :) I don't *want* Lisp's GC.
>
> It's not optimized for my language, and if a new advance comes along I
> either have to wait for the creator of the Lisp implementation I am
> using to switch to it, or hack on the Lisp Compiler/whatever myself,
> which will likely be in C that I'm trying to avoid. :)
What, and a nice little project like getting rid of all those wasted 24
bits in the first word of every instance in SBCL wouldn't be fun?
Seriously, I can see that it is not ideal to make compromises on speed
and memory efficiency and having to cater to design choices in the rest
of the Lisp if your design goal is just optimal speed of the other VM,
not integration into the Lisp.
But should that not be the whole point of implementing a foreign
language directly in Lisp? You could certainly let two language
runtimes co-exist in the same process using minimal interaction between
them, but then you might as well let them run in different processes.
On Jun 19, 6:15 pm, David Lichteblau <···········@lichteblau.com>
wrote:
> On 2007-06-19, Jason <··········@hotmail.com> wrote:
> But should that not be the whole point of implementing a foreign
> language directly in Lisp?
Why? My point is to make the most efficient, fast, etc. VM I can and
not take 20 years to do it (i.e. using C/C++). But I don't want any
design choices put on me by the language I use for implementation.
In article <·······················@e9g2000prf.googlegroups.com>,
Jason <··········@hotmail.com> wrote:
> On Jun 19, 2:38 pm, David Lichteblau <···········@lichteblau.com>
> wrote:
> > On 2007-06-19, Jason <··········@hotmail.com> wrote:
> >
> > > Now I'm sure I could use Lisp to do this, but the problem I think I
> > > would have using regular common lisp is that it will include GC code
> > > etc. Of course programming with a GC makes things easier, but it
> > > seems like a bad idea to implement a VM with generational GC etc. with
> > > a language that has it's own GC already.
> >
> > I would just use Lisp objects to implement the objects of the VM being
> > implemented. Re-use the Lisp's GC instead of implementing your own.
>
> I appreciate your effort to save me time, but I'm not trying to get
> this implemented as fast as possible. :) I don't *want* Lisp's GC.
I don't think there should be any conflict. If you use a big array to
represent the VM's memory, it will never be GC'ed. Lisp's GC will only
operate on the internal data within the VM implementation, not on the
virtual data.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Jun 19, 2:38 pm, David Lichteblau <···········@lichteblau.com>
wrote:
> On 2007-06-19, Jason <··········@hotmail.com> wrote:
>
> > Now I'm sure I could use Lisp to do this, but the problem I think I
> > would have using regular common lisp is that it will include GC code
> > etc. Of course programming with a GC makes things easier, but it
> > seems like a bad idea to implement a VM with generational GC etc. with
> > a language that has it's own GC already.
>
> I would just use Lisp objects to implement the objects of the VM being
> implemented. Re-use the Lisp's GC instead of implementing your own.
>
> > Thanks in advance for any pointers anyone could provide, as I suspect
> > there are such things out there and I just haven't had success finding
> > them.
>
> Start using DEFSTRUCT for your objects.
>
> Then if the overhead of your implementation's class definition scheme
> turns out to be too large, there is probably room for optimization using
> implementation-dependent machinery.
>
> For example, in SBCL I create my own LAYOUTs to avoid setting up actual
> class definitions while still creating different kinds of instances, and
> I subclass LAYOUT to install extra information about those classes,
> including a vtable for method dispatch.
This sounds very interesting. Could you please give me some example or
point me to some documentation how to make/manage layouts?
Cheers,
Karol Skocik
On 2007-06-19, Karol Skocik <············@gmail.com> wrote:
>> For example, in SBCL I create my own LAYOUTs to avoid setting up actual
>> class definitions while still creating different kinds of instances, and
>> I subclass LAYOUT to install extra information about those classes,
>> including a vtable for method dispatch.
>
> This sounds very interesting. Could you please give me some example or
> point me to some documentation how to make/manage layouts?
OK. You asked for it. (Don't do this at home!)
Here is a simple example for a structure class FOO with just one slot.
We create instances of FOO that have more than one slot. To the rest of
the runtime, our special objects look like direct instances of FOO, but
garbage collection knows about the extra slots because it is just
interested in the layout, not the defstruct description.
(defstruct (classlike (:include sb-kernel:layout))
extra-info)
(defun make-subclasslike-layout
(super n-tagged-slots n-untagged-slots extra-class-info)
(let ((base-layout (sb-kernel::compiler-layout-or-lose super)))
(make-classlike
:classoid (sb-kernel:layout-classoid base-layout)
:inherits (concatenate 'simple-vector
(sb-kernel:layout-inherits base-layout)
(vector base-layout))
:depthoid (1+ (sb-kernel:layout-depthoid base-layout))
:length (+ (sb-kernel:layout-length base-layout)
(or n-tagged-slots 0)
(or n-untagged-slots 0))
:n-untagged-slots (or n-untagged-slots 0)
:invalid nil
:info (sb-kernel:layout-info base-layout)
:extra-info extra-class-info)))
(defstruct foo a)
(defvar *subclasslike-layout*
(make-subclasslike-layout 'foo 2 0 "extra-class-info"))
(defun foo-extra-slot-1 (x) (sb-kernel:%instance-ref x 2))
(defun foo-extra-slot-2 (x) (sb-kernel:%instance-ref x 3))
(defun (setf foo-extra-slot-1) (nv x) (sb-kernel:%instance-set x 2 nv))
(defun (setf foo-extra-slot-2) (nv x) (sb-kernel:%instance-set x 3 nv))
(defun extra-class-info (x)
(classlike-extra-info (sb-kernel:%instance-layout x)))
(defun make-subclasslike-instance (x1 x2)
(let ((x (sb-kernel::%make-instance-with-layout *subclasslike-layout*)))
(setf (foo-extra-slot-1 x) x1)
(setf (foo-extra-slot-2 x) x2)
x))
(let ((x (make-subclasslike-instance 42 34)))
(print (foo-a x))
(print (foo-extra-slot-1 x))
(print (foo-extra-slot-2 x))
(print (extra-class-info x))
x)
On Jun 19, 6:20 pm, David Lichteblau <···········@lichteblau.com>
wrote:
> On 2007-06-19, Karol Skocik <············@gmail.com> wrote:
>
> >> For example, in SBCL I create my own LAYOUTs to avoid setting up actual
> >> class definitions while still creating different kinds of instances, and
> >> I subclass LAYOUT to install extra information about those classes,
> >> including a vtable for method dispatch.
>
> > This sounds very interesting. Could you please give me some example or
> > point me to some documentation how to make/manage layouts?
>
> OK. You asked for it. (Don't do this at home!)
>
> Here is a simple example for a structure class FOO with just one slot.
> We create instances of FOO that have more than one slot. To the rest of
> the runtime, our special objects look like direct instances of FOO, but
> garbage collection knows about the extra slots because it is just
> interested in the layout, not the defstruct description.
>
> (defstruct (classlike (:include sb-kernel:layout))
> extra-info)
>
> (defun make-subclasslike-layout
> (super n-tagged-slots n-untagged-slots extra-class-info)
> (let ((base-layout (sb-kernel::compiler-layout-or-lose super)))
> (make-classlike
> :classoid (sb-kernel:layout-classoid base-layout)
> :inherits (concatenate 'simple-vector
> (sb-kernel:layout-inherits base-layout)
> (vector base-layout))
> :depthoid (1+ (sb-kernel:layout-depthoid base-layout))
> :length (+ (sb-kernel:layout-length base-layout)
> (or n-tagged-slots 0)
> (or n-untagged-slots 0))
> :n-untagged-slots (or n-untagged-slots 0)
> :invalid nil
> :info (sb-kernel:layout-info base-layout)
> :extra-info extra-class-info)))
>
> (defstruct foo a)
>
> (defvar *subclasslike-layout*
> (make-subclasslike-layout 'foo 2 0 "extra-class-info"))
>
> (defun foo-extra-slot-1 (x) (sb-kernel:%instance-ref x 2))
> (defun foo-extra-slot-2 (x) (sb-kernel:%instance-ref x 3))
> (defun (setf foo-extra-slot-1) (nv x) (sb-kernel:%instance-set x 2 nv))
> (defun (setf foo-extra-slot-2) (nv x) (sb-kernel:%instance-set x 3 nv))
>
> (defun extra-class-info (x)
> (classlike-extra-info (sb-kernel:%instance-layout x)))
>
> (defun make-subclasslike-instance (x1 x2)
> (let ((x (sb-kernel::%make-instance-with-layout *subclasslike-layout*)))
> (setf (foo-extra-slot-1 x) x1)
> (setf (foo-extra-slot-2 x) x2)
> x))
>
> (let ((x (make-subclasslike-instance 42 34)))
> (print (foo-a x))
> (print (foo-extra-slot-1 x))
> (print (foo-extra-slot-2 x))
> (print (extra-class-info x))
> x)
Thanks for nice example! If I understand correctly, this could be a
nice way to make instances of structure classes behave like prototype
objects while still enjoying the advantages of method dispatch. It
would be interesting to know whether you can get this kind of behavior
portably using clos/mop.
Have a nice day,
Karol Skocik
Jason <··········@hotmail.com> writes:
>
> Now I'm sure I could use Lisp to do this, but the problem I think I
> would have using regular common lisp is that it will include GC code
> etc. Of course programming with a GC makes things easier, but it
> seems like a bad idea to implement a VM with generational GC etc. with
> a language that has it's own GC already.
Why not let the Lisp GC manage the hosted language's objects? Saves you
from having to write your own GC...
> That is, there should be a high level'ish language that one can build
> low level things like OS'es, VM'es etc. in.
Common Lisp can serve in that role.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Every citizen [should] be a soldier. This was the case with the Greeks
and the Romans, and must be that of every free state. --Thomas Jefferson
On Jun 20, 6:04 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Jason <··········@hotmail.com> writes:
>
> Why not let the Lisp GC manage the hosted language's objects? Saves you
> from having to write your own GC...
Because I don't want to be saved from it. :)
You may be interested in Ian Piumarta's work.
papers: http://piumarta.com/pepsi/
source: http://piumarta.com/svn2/idst/
I'd recommend starting with his presentation video at the Stanford
Colloquium, links are here for the video and slides - if you haven't
seen it yet, it's well worth your time :
http://www.peerbox.com:8668/space/Albert (just look for the Stanford
links)
You find a subset of Smalltalk-80 is implemented and used by the
compiler.. His work is inspired by Lisp, Smalltalk, TeX and other
great things. This
work is a backbone for Alan Kay's work with the NSF grant
http://www.vpri.org/html/work/ifnct.htm
-Don
On Jun 19, 2:23 am, Jason <··········@hotmail.com> wrote:
> Hello all,
>
> I apologize if this has been asked before (and no doubt it has at some
> point, I just couldn't find it). I am interested in experimenting
> with creating a VM for Smalltalk (or maybe a hybrid Smalltalk :), but
> I wish to use a high level language for this. I wont do it if I have
> to use C/C++. Partly because I don't want to make any more projects
> in these languages and partly because I want the full power I can get
> from the CPU (e.g. catch integer overflow).
>
> Now I'm sure I could use Lisp to do this, but the problem I think I
> would have using regular common lisp is that it will include GC code
> etc. Of course programming with a GC makes things easier, but it
> seems like a bad idea to implement a VM with generational GC etc. with
> a language that has it's own GC already.
>
> For those of you who would try to convince me that this isn't a
> problem, I appreciate your efforts in saving me time, but I really
> think this is a space that needs to be filled. That is, there should
> be a high level'ish language that one can build low level things like
> OS'es, VM'es etc. in. I know we all want to say "premature
> optimization" and various other, correct statements about this, but in
> my opinion as long as it remains this way people will always be tied
> to C/C++.
>
> Thanks in advance for any pointers anyone could provide, as I suspect
> there are such things out there and I just haven't had success finding
> them.
>
> Sincerely,
> Jason