Re: Issues in ia64

[cr88192 sydney]

> 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
>    directory...
>
> 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...
>  
> http://www.glug.org/docbits/guile-doc-out/html/guile-1.7.0/guile_25.html#SEC237
>
> 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: http://mobile.msn.com