[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues in ia64
Re: Issues in ia64
Wed, 03 Jul 2002 00:58:17 +0000
in my implementation (except for ports and a few other things), all
interaction with the ouside world is done by "sa_*" functions, everything
else is provided by the vm. ports sadly are tied into an external io
subsystem (mostly), luckily that io subsystem is also part of my code base
and is usually used with my vm. I still don't like this, but the only real
alternative would be to strip off file interaction with the outside world or
wrap the whole io subsystem with more sa_* functions (which would be
annoying as my io subsystem is a little bulky and this could only provide a
dumbed down interface, though that is all r5rs asks...).
for example, getpwent binding (glue code) can be put into a shared
object library and then we can arrange for guile to load that library
automatically on first reference to `getpwent'. all this is "can"
because no one has actually done it yet. part of the problem is
settling on methodology to make this particular separation an instance
of the larger task of "supporting modular development". everything can
be done by hand but that gets old...
what I had done with it would was using it as a lib, but all the
"normal" extensions loaded in (ice-9, guile-gtk, ...). didn't work
and couldn't be loaded without putting them in the current
did you load boot-9.scm? this defines the module system, which is what
searches `%load-path' for those things.
oh, ok. I guess this would fix it.
ok, the real issue is that I don't know guile's workings in detail...
i'm in the same boat (whatever level of detail i know, there's always a
I know my vm, as I wrote the whole thing...
well it should be all this (except maybe the last one). the spec also allows
code to "break from the spec". though the spec can be broken it could be
considered less safe (thus when dealing with certain parts of the stack the
collector would need to be conservative and it would be pinned). my spec is
fussy but it should not be impossible.
it will need to be redesigned for other archs though, but even then it will
not be too much different. I think x86 is about the lower limit of usable
registers (where only eax, ecx, and edx are defined as being usable for
data...). I am considering changing the design to allow a "scratchpad"
space, which would work like extended registers though data there would be
conservative (requiring precise data to be on the stack...).
I have for a while been considering writting a compile system, I had
written a general spec for the calling convention and how to handle
precise gc/relocation/swizzling for the stack, if wanted I may be
able to make the partial spec available. are there any real important
issues for this?
important issues for compilation are everywhere. important issues for
your spec are that it be complete, consistent and implementable. less
clearly important (i.e., may be important to some people but not to you)
is that it interoperate w/ current designs, to aid experimentation.
in my spec call/cc is accomplished by copying the pages from the
stack region into a continuation region and setting the real stack
copy-on-write, is this good?
i don't know enough about the particulars to answer this.
ok then, seems good to me in cases where continuations are stack allocated.
question: in guile anyways is it possible to supply your own mm and
to inquire about the structure of objects? is there a spec on the
structure of objects as well?...
guile implements a mini language for specifying object layout in memory.
see libguile/struct.c `make-struct-layout'. user-level docs are in the
manual under node `Structures':
ok cool, is the whole object system done this way?
my object system is a little more ad-hoc though, but it needs a good
I mean, can you replace the cons/object allocator with your own functions,
ie: so you could allocate from a store. actually mine does this but it is
currently hard coded (though I later hope to allow user defined memory
i don't know what "your own memory management" means, precisely.
certainly guile abstracts malloc and free for its own use internally.
sadly in my spec at least some external mm is needed, though probably for
init of something like an os kernel a small pool could be used.
I have changed projects so sadly the compile system is not really
Send and receive Hotmail on your mobile device: http://mobile.msn.com
- Re: Issues in ia64, (continued)