On Apr 9, 5:21 am, Albert van der Horst <alb...@[EMAIL PROTECTED]
>
wrote:
....
> There is no reason to use elf if it is not native. There is no
> reason that things would get more complicated.
Hmm.. maybe but I get the feeling most IA-32 *nix's support elf in
some form. As I understand it even FreeBSD binaries are elf. I don't
know that it wouldn't be that difficult for Apple to have support for
both heh.. But anyways, pondering about that won't change things.
Albert:
> I wote:
> >If anyone's so inclined to advise me on how to 'section' out the
> >source code a little better I'd be very grateful.
>
> Ah. I saw you made the dictionary a .text section.
> That will not result in a fully usable Forth.
Actually I put the .text immediately on the line before the .data
directive. The apple NASM 0.98 would not assemble it as a mach-o
without the .text section.
To put this in context for everyone, I am using NASM (apple Xcode 3.0)
0.98 to assemble a patched Albert's lina into mach-o binary (which was
originally meant to build elfs on linux)
> Sections have independant properties:
> 1. they can be protected against writing once loaded
> (we don't want that in classic Forth, variables couldn't be
> changed)
My limited understanding (and trial and error lol) taught me that - I
finally realized that so I put all the code in a .data segment as
stated above (from the entry point start)
As you say I initially put all the code bits in a .text segment but
the kernel grumbled about it on excecution - and rightly so.
The version you downloaded can write to the dictionary. It also does
create does> and allot as far as my initial testing goes. Or should I
say CREATE DOES> etc (I hadn't realised intiially it was case
sensitive, heh).
I found out however at the moment whenever I try and call an undefined
word (say) from the interpreter it goes as far as printing xx? and
bombs.. I'll have to trace this.
I have to admit I'm still not completely familiar with the tools I
have on my mac. Apparently the Xcode gdb version is really good, so
that's what I'm working on figuring out now.
> 2. they can be in the disk image
> (we want that for the occupied dictionary space,
> but not for the 256 Mbyte of free dictionary space)
> 3. They can be protected against execution.
> (we don't want that, primitive words couldn't be executed)
>
> .text is a protected against writing, but not against execution,
> unusable for forth.
> .data has the protections reversed, equally unusable.
> The trick is to get rid of those sections in a c-world where
> both types are deemed indispensible and find out how to spell
> out the correct properties towards the assembler.
> We want sections:
> kernel: readable writable executable, in the image ("bits")
As I understand it as of now mach-o .data segments allow read/write/
exec else the code wouldn't have run. I had to put in the .text
segment before that to get it to assemble. Maybe that problem is
solved
> dictionary: readable writable executable, not in the image.
I don't quite get what you meant 'not in the image' - does this imply
uninitialized datat?
Trying to get the dictionary space section initialised however is
tricky. I looked up some ELF documentation and saw that .bss was for
unitialized data, took a chance, put it in and it seemed to assemble
and link. I'm still not sure if that's the proper way to do it.
If I left it without the .bss directive I got an obj that was close to
67 megs big and an executable (which still ran!!) about the same
length as I am guessing it allotted and zeroed it out
As I understand it, when you assemble/link a Lina elf, essentially
the executable contains the engine and the prebuilt words in a named
'forth' section/segment and the dictionay builds from the 'dictionary'
section/segment which is pretty much uninitialised and hence does not
get allotted into the exe file, but onto the memory map of the process
on loading and execution of the elf.
I think I've managed to get this going, whether this is the correct
form for mach-o or not I am still not sure. The assembler got very
annoyed with me when I tried to call the section with the code 'forth'
> I wrote:
> >Also I've been sleeping over what you said about the LINOS, Albert.
>
> >I think it would probably be best in the end to build a completely
> >independent macho-o OS X forth fork with a XNUOS word for example as,
> >as you say, there will be times when one will want to call XNU direct.
>
> I see that it would be better to rename the word to POSOS. (Posix
> OS call) or XOS (uniX family Operating System Call)
> The usage would not be much different between the Linux,BSD
> and OSX. The implementation would be only slightly different.
> In that way most of the library stays intact.
Hmm...I'll see how different the calls are when I get a chance and
think of a way to work round this.
What will really throw a spanner in the works however is if Apple
decides down the track that most people will call the kernel via a c
libary (ie 'their' c library or whatever proprietary library they may
build) and change the more primitive things around. Or maybe this has
already happened. I'll have to look at the XNU source.
> By the way, I don't fork. I have a sophisticated generic system.
> (Everybody is entitled by the GPL to fork if he wishes too, though.)
Re: fork - Ok maybe wrong choice of words :) If I ever get an OS X
version running I intend it to be as close to ciforth as possible.
Maybe if it's bug free enough it may return to you if you want it
heh...
I've still your source to dissect and it seems really very elegant and
clever, just one tiny engine and everything else is in the dictionary.
> The first thing to try is just leaving it to a native assembler and
> a native linker. They know best how native executables look like.
> Forget about elf. The wina version is not elf either.
Sure. Been doing that with the (apple) NASM which is set up to build
mach-o. And the apple ld.
Maybe I will have to look at gas. But, you know, truth be told, mea
culpa, part of my growing up was done on m$-dos/windoze. So you can
see where my prejudice lies. As far as I can tell the gas supplied
with Xcode is < 2.0.
I don't like the AT&T syntax an order of operands and it would seem
that the apple version does not allow the intel order of operands
directive.
> Nice to see someone building on.
Nice to see some nice source to play with :)
I still don't understand a lot about forth, *nix etc. This is an
excellent learning opportunity, thanks to you.
-----------
TO DO LIST:
-----------
1. Build mach-o binary correctly. This means understanding the load
process, memory map expected of a program of this sort, and how you
expect your source code to assemble and live in memory as well.
- Regarding the ELF Lina source: I think I can understand how the
initial engine and prebuilt words get set up in memory but I still
don't understand how the ELF loader does your dictionary. The
priviledges bit I undestand but where does it locate it in memory?
Where should it locate it in a mach-o.. questions questions heh...
2. Find out why the console interpreter bombs with undefined words
(bad syscall) - probably an incompatible syscall I guess. I'll have to
debug.
3. Write an alternative POSOS call word and/or make LINOS etc
compatible with the XNU. See (2)
4. SAVE-SYSTEM ... heh.
I think I will cheat and write some c to see what it assembles to -
wish I could get gcc to assemble to nasm so I can't read it without a
headache though.
Robert Spykerman
|
