In article
<09ce06bd-a686-4138-8ea4-c15a585330fa@[EMAIL PROTECTED]
>,
Robert Spykerman <robert.spykerman@[EMAIL PROTECTED]
> wrote:
>On May 3, 2:46 am, Albert van der Horst <alb...@[EMAIL PROTECTED]
>
>wrote:
>
><SNIP>
>
>> It may be frowned upon, but adapting lina to new versions of
>> OS's is probably less effort than gforth keeping up with new
>> version of gcc.
>
>In truth, even for a noob like me, it so far has been quite easy to
>****t lina to OS X.
>
>This is a reflection of the original source, which although sparsely
>commented I've found quite easy to read, in general.
>
>More comments in the forth source would be good though, as an
>afterthought, Albert if it's convenient while you are patching the
>source for version 5.
What you are seeing is generated source for me. The real source
is the generic file ci86.gnr. I'm about to start integrating
OSX with version 5.36 of ci86.gnr right now.
In the generic source each word is accompanied with its documentation
there and a few test cases.
What you are doing is appropriate for small changes, and is
called level 3 customization. (See the pdf of the generic system).
The great thing about level 3 customization is that a competent
engineer can do quite a lot without having much more than the source
and knowledge of assembler language, as you have demonstrated.
To be effective in level 3 it may mean that you have to look into the
generated docs. So if you want to change details about how ABORT
behaves in the generated source, you should look up ABORT in the
generated docs, i.e. the regular lina pdf file for 4.0.6
On level 4 the starting point is ci86.gnr
There e.g. a code header looks like
_CODE_HEADER({+},{PLUS})
and a colon definition looks like
_HEADER({.S},{DOTS},{DOCOL})
Leaving out a word is trivial. More difficult things are possible,
but there is a learning curve.
>Much of the slowness has been unavoidable real life commitments, and
>just trying to find the docs/info and understanding what's actually
>going on (being new to nix - which is actually one reason why I'm
>doing this at all as well).
>
>Small is beautiful and given major kernel changes are not particularly
>frequent, I can't really see why this approach is very very bad - it
>just means rooting around for the changes if stuff breaks.
If lina breaks, the amount of c-code that breaks in e.g. linux is
really enormous. I'm sure I can keep up. In fact there has been only
one change ever in Linux, that affected lina. That was the
introduction of the .intelsyntax in gas. It was beneficial, because
now lina can be build with only system supplied tools.
>Naughty perhaps. But looking at how well linux generally appears to be
>documented with good backwards compatibility, this appears to be less
>of an issue with linux.
Naughty from the pov of c. From the pov of Forth it may be great.
Of course, the c-guys don't want a compiler that competes with
c. At this point there is no competitor for c except lina.
All other compilers are dependant of c and of c-libraries.
The c-libraries are written with fruits of the
forbidden tree of knowledge of the uniX system calls.
Will Forth be doomed for eating from that tree? We'll see.
At least in a world of bloat, lina is there to show to the world the
benefits of static linking and minimalistic system resource use. (lina
works on linux version 1.2, wina works from XP to Windows 3.11 with
system32 extension, and on dosemu).
Maybe some day we can show linux libraries written in Forth,
with some Forth specific benefits.
The forbidden fruits cannot be had without effort.
The interfaces are specified in c, and the constants are hidden
in header files that are hard to find (except if you are a c-compiler
and Linus has learned you a lot of tricks).
>Gotta start working out the SAVE-SYSTEM now. But for ultimate
>compatibility after that's done I will probably do one with a static
>link to the c-lib for OSX. I'm not sure I like the idea of a dynamic
>link, but I'll look at this too (namely because I don't know how to do
>one).
I expect the naughty way to be more successful. I foresee that
understanding Mach-o headers is easier than using the c-lib and
facing the linking issue.
Just hacking the headers will me *much* easier.
We'll see.
>Robert Spykerman
Good luck and 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
|
