[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issues in ia64

From: cr88192 sydney
Subject: Re: Issues in ia64
Date: Wed, 03 Jul 2002 00:58:17 +0000

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...

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...).

   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
deeper level).

I know my vm, as I wrote the whole thing...

   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.

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...).

   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 cleaning...

i don't know what "your own memory management" means, precisely.
certainly guile abstracts malloc and free for its own use internally.

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 managment...).

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 needed/usable...

Send and receive Hotmail on your mobile device:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]