In article
<ff322552-0c05-47b1-b7cd-81e02230529e@[EMAIL PROTECTED]
>,
Robert Spykerman <robert.spykerman@[EMAIL PROTECTED]
> wrote:
>On Apr 8, 8:18 am, Albert van der Horst <alb...@[EMAIL PROTECTED]
>
>wrote:
>...
>> Use a standard assembler if available.
>> Use the standard linker.
>> See what happens.
>> E.g. with nasm on linux
>> nasm -felf lina.asm -o lina.o
>> ld lina.o -o lina
>> It doesn't get much simpler than that.
>> It worked when I knew nothing more about the elf-format
>> than that it existed.
>> Now SAVE-SYSTEM was a little more work.
>
>You said it.
Don't be intimidated. A little hacking works wonders.
>
>It is as I feared. I am now fairly convinced after a bit of googling
>that elf's are a no-go on OS X. For example:
>
>http://macslash.org/article.pl?sid=07/02/24/0114221
>
>http://0xfe.blogspot.com/2006/03/how-os-x-executes-applications.html
>
>mach-o's look a little bit complicated, but I'm sure with time I'll
>figure it out.
There is no reason to use elf if it is not native. There is no
reason that things would get more complicated.
>
>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.
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)
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")
dictionary: readable writable executable, not in the image.
>
>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.
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.)
>
>Then port the libraries.
There is one library, with conditional parts (LAB file). It
handles MSDOS WINDOWS linux32 and linux64. I'm sure it can handle
OSX in addition. This system has the property, if it doesn't
work, you can't load it. Large parts are unconditioned.
The assembler would load, and be operational, because it
doesn't contain Operating System related conditions.
>
>In the interim, if I mark out the differences between linux and the
>XNU kernel, I may be able to make the LINOS words compatible with old
>code. This may be a lot more work than I imagine if not just the
>function/jumptable indices differ, but if the number of parameters/
>returns differ.
>
>I might look at the BSD linux compatibility layer source for hints -
>assuming XNU follows BSD closely.
The system calls in the Forth kernel are very basic, mostly file
related. There is little variance between X-operating systems for
those. So I'm quite optimistic here. SYSTEM is an exception.
But in the ciforth philosophy SYSTEM calls a shell and doesn't
try to execute a program directly.
>
>The most pressing thing however is to see if I am actually making mach-
>o binaries correctly. So if anyone with experience building OS-X IA-32
>binaries could look and advise I would be very grateful.
>
>I'm sure there is a some reason why apple chose to use mach-o's
>exclusively but I can't see why they left out support for elfs. It
>would make porting much easier.
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.
This is how the Dec Alpha lina version builds:
as lina.s -o lina.o
ld lina.o -o lina
As I said, it doesn't get much simpler than that.
(These are the GNU as and ld.)
>
>Thanks very much
Nice to see someone building on.
>
>Robert Spykerman
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@[EMAIL PROTECTED]
&=n http://home.hccnet.nl/a.w.m.van.der.horst
|
