Snapshot 5.37 of xina
Albert van der Horst
generic ciforth system version 5.
Via ciforth.html you can arrive at my ftp site for xina.
( Or from the top of my home page.)
This is the readme file you can find there.
All comments are welcome!
Output of tests (test.xina.1) are particularly welcome!
This is not even beta, you must build your own executable,
and it may not even run, much less flawlessly.
If you know about OSX, you may answer the questions in
OSX. Everything wrong there is wrong in the pdf file.
---------------------------------
2008 may 4 by Albert van der Horst
This ftp directory contains current efforts regarding osx.
Remember xina is an abbreviation of
"osX lINA compatible version of ciforth".
That is the abbreviation that occurs in all the files.
RUN :
build with ci86.xina.asm according to the instructions in the source.
Place the library file forth.lab in the same directory.
Enjoy.
DOC
The .pdf should be generally okay, but I'm not sure about the points
in "osx.txt". All remarks are welcome.
TEST
Run the testxina.1 test through xina via indirection.
The result should be testxina.2, ignoring blank space and version
number.
Notification of difference are welcome.
LIST OF FILES
ci86.gnr Generic source
xina.cfg xina configuration file
ci86.xina.asm Source for xina, configured
ci86.xina.pdf Documentation
disclaimer.txt In case xina is a trademark.
forth.lab.lina The library file.
osx.txt Check for for documentation
stealconstant.c Run this for constants.
testxina.1 Tests to be run via indirection
testxina.2 Intended result of test.
readme.txt This file
---------------------------------
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Robert Spykerman
wrote:
> I have integrated Robert Spykerman's OSX version into the
> generic ciforth system version 5.
Thanks - you've just saved me a lot of effort. I haven't learnt how
your generic ciforth generator works yet - ie m4 etc.
The toughest part to those of you who want to give this a whirl was
porting lseek and fork calls. So file related words (ie the block
system) and the SYSTEM word were the hardest. If you're trying, I
would suggest to check this to make sure it works first.
Apart from that it was just revectoring other syscalls which appear to
work.
I'll get this ciforth version and give it a go later and see how it
builds, but for now I've got to get over this flu first:) Damn
viruses. You gotta hate them. lol.
Robert Spykerman
Robert Spykerman
> generic ciforth system version 5.
<SNIP>
I have sent Albert some minor corrections which cause the
ci86.xina.asm to bomb on execution (samely the syscall access words).
Words that use XOS, XOSV, SYSTEM and SHELL are affected and these 4
words have been ammended.
The test suite has uncovered at least one problem with CREATE-FILE.
(Wow, that test suite is pretty rigorous).
I will be checking this out. No doubt this is related to syscalls. Oh
what fun :)
Robert Spykerman
Robert Spykerman
wrote:
<SNIP>
> The test suite has uncovered at least one problem with CREATE-FILE.
> (Wow, that test suite is pretty rigorous).
>
> I will be checking this out. No doubt this is related to syscalls. Oh
> what fun :)
Yep, syscalls. What fun.
OSX does not have creat anymore. So I've added functionality via the
open syscall. This appears to work now. Will test more.
Also, the open syscall behaves slightly differently on OSX cmp linux.
For example, if you try and open a non-existent file on linux you get
a negative return (error). On osx, you get a 2 returned in EAX when
you open a non-existent file or if you try and open a directory. I
assume it means stderr. Any file that exists appears to get a fid >=
4.
Now of course, one could add some extra cheat logic to cope for the
difference, like I did for the fork syscall. This however means less
genericity in the syscall words, as each substantially different
syscall will have to have a word of its own.
Alternatively have a jumptable in just one word ie XOS which will
dispatch the syscall to its appropriate patch within just to mantain
lina compatibility (ie so the forth.lab syscalls don't break).
It sure looks like the only way to get consistency here may be
ultimately to call c and abandon syscalls altogether. Linux may be
consistent with linux, but OS X and linux.... OS X is certaintly
turning out to be quite the black box at syscall level and I have been
warned by a guy at apple not to do this. hmmm....
I'll stick at this for a while, but I'll aim to link to c down the
line. From what I know the big *nix forths, gforth, iForth (I think -
have't got a copy yet) and VFX link to c libs.
Robert Spykerman
Bruce McFarling
wrote:
...
> Now of course, one could add some extra cheat logic to cope for the
> difference, like I did for the fork syscall. This however means less
> genericity in the syscall words, as each substantially different
> syscall will have to have a word of its own.
> Alternatively have a jumptable in just one word ie XOS which will
> dispatch the syscall to its appropriate patch within just to mantain
> lina compatibility (ie so the forth.lab syscalls don't break).
The way that I saw this done in '86 assembly was with a macro system.
That was spanning Linux and what I took to be BSD descendents ...
Unixware, Solaris, AtheOS, and BeOS, so I have no idea how well it
extends to OSX.
Albert van der Horst
Robert Spykerman <robert.s...@gmail.com> wrote:
>On May 5, 2:00 pm, Robert Spykerman <robert.spyker...@gmail.com>
>wrote:
><SNIP>
>
>> The test suite has uncovered at least one problem with CREATE-FILE.
>> (Wow, that test suite is pretty rigorous).
>>
>> I will be checking this out. No doubt this is related to syscalls. Oh
>> what fun :)
>
>Yep, syscalls. What fun.
>
>OSX does not have creat anymore. So I've added functionality via the
>open syscall. This appears to work now. Will test more.
>
>Also, the open syscall behaves slightly differently on OSX cmp linux.
>For example, if you try and open a non-existent file on linux you get
>a negative return (error). On osx, you get a 2 returned in EAX when
>you open a non-existent file or if you try and open a directory. I
>assume it means stderr. Any file that exists appears to get a fid >=
>4.
>
>Now of course, one could add some extra cheat logic to cope for the
>difference, like I did for the fork syscall. This however means less
>genericity in the syscall words, as each substantially different
>syscall will have to have a word of its own.
Where we aim for is a Forth OPEN-FILE that is consistent across
systems. So the OPEN-FILE in the generic system selects between
an OSX and a linux (and a Windows, and an MSDOS) implementation.
This is no different from the situation with REPOSITION-FILE.
>Alternatively have a jumptable in just one word ie XOS which will
>dispatch the syscall to its appropriate patch within just to mantain
>lina compatibility (ie so the forth.lab syscalls don't break).
That is a kind of compatibility I don't seek. The library should
make available words that are functionally the same across
systems. If the implementation is different then the library
caters for that.
For example:
The windows SAVE-SYSTEM has an index line
( SAVE-SYSTEM ) CF: ?WI
The regular linux SAVE-SYSTEM has an index line
( SAVE-SYSTEM ) CF: ?LI ?32
The 64 bit linux SAVE-SYSTEM has an index line
( SAVE-SYSTEM ) CF: ?LI ?64
The OSX SAVE-SYSTEM will get an index line
( SAVE-SYSTEM ) CF: ?OX
If there is an underlying open system call, instead of creat,
fine. Certainly the windows SAVE-SYSTEM uses totally different
underlying calls.
If a facility merely requires 32 bits it looks like
( CRC ) CF: ?32
If there are facilities portable across Unices I will introduce
?X for that.
The -c screen (3) takes care of compilation. It is the same across
all ciforth's, and uses SAVE-SYSTEM.
<SNIP>
>
>I'll stick at this for a while, but I'll aim to link to c down the
>line. From what I know the big *nix forths, gforth, iForth (I think -
>have't got a copy yet) and VFX link to c libs.
There is a place for a different approach.
>
>Robert Spykerman
Robert Spykerman
http://xina.cvs.sourceforge.net/xina/xina-generic/
(I'm going to restructure the directory tree soon)
So at the moment, it would appear that xina behaviour is quite close
to lina on linux. I would say nearly identical but I have not done
nearly enough testing to confidently say this yet. Need some brave
souls to put it thru' its paces and find other bugs.
Bascially SAVE-SYSTEM is implemented on OS X much the same way as
Albert's original linux one - changing the loader header commands.
1. I found the thing that worked is fudging the load __DATA segment
lengths. Although there is only a declared __bss section in the said
segment, altering the initial length of zero to whatever you need and
writing the binary back works.
2. However, the __LINKEDIT segment is loaded high. Choices are to try
and preserve it or leave it out. At present, I've decided to let it go
and have nuked the load __LINKEDIT segment command. Fortunately the
mach-o loader doessn't seem to mind this bit missing. This segment
will likely be preserved in future iterations when I try and get
external dynamic library calls implemented.
3. Only the forth high level source was changed for this addition
(forth.lab). To get SAVE-SYSTEM loaded you need to run the binary with
-a to load forth.lab and WANT SAVE-SYSTEM.
Appreciate all bug reports etc. Thanks.
Robert Spykerman
Albert van der Horst
Robert Spykerman <robert.s...@gmail.com> wrote:
>I've just added SAVE-SYSTEM / TURNKEY to xina.
>
>http://xina.cvs.sourceforge.net/xina/xina-generic/
>(I'm going to restructure the directory tree soon)
>
>So at the moment, it would appear that xina behaviour is quite close
>to lina on linux. I would say nearly identical but I have not done
>nearly enough testing to confidently say this yet. Need some brave
>souls to put it thru' its paces and find other bugs.
Your hard work inspires me. Tomorrow I have a Forth session with
Coos Haak (a c.l.f contributor and author of chForth).
We will try to integrate all stuff and have a new version 5.0
snapshot, with corresponding testsets, and probably a pdf manual.
OS X will get an official abbreviation, such that it can use the
common blocks.frt that goes into forth.lab.
This means that it gets a block for its own SAVE-SYSTEM
with an index line like
( SAVE-SYSTEM TURNKEY ) CF: ?OX
The next thing to do is to run the testsets. This can only
be done on an OSX system. In the meanwhile I can do some
inspection of how the documentation falls out.
There after it will be necessary to look into the error codes.
Error codes returned by OS X will need to go into
forth.lab. (The error codes are the only system dependant part
of forth.lab.) Then we will be pretty well set.
>
>Bascially SAVE-SYSTEM is implemented on OS X much the same way as
>Albert's original linux one - changing the loader header commands.
>
>1. I found the thing that worked is fudging the load __DATA segment
>lengths. Although there is only a declared __bss section in the said
>segment, altering the initial length of zero to whatever you need and
>writing the binary back works.
>
>2. However, the __LINKEDIT segment is loaded high. Choices are to try
>and preserve it or leave it out. At present, I've decided to let it go
>and have nuked the load __LINKEDIT segment command. Fortunately the
>mach-o loader doessn't seem to mind this bit missing. This segment
>will likely be preserved in future iterations when I try and get
>external dynamic library calls implemented.
>
>3. Only the forth high level source was changed for this addition
>(forth.lab). To get SAVE-SYSTEM loaded you need to run the binary with
>-a to load forth.lab and WANT SAVE-SYSTEM.
There is a good chance that you can compiler programs with
-c have you tried that?
Like
echo ': MAIN ." Hello world" CR ;' >h.frt
xina -c h.frt
The -g options is somewhat trickier, I guess.
>
>Appreciate all bug reports etc. Thanks.
>
>Robert Spykerman
Robert Spykerman
wrote:
<SNIP>
> There after it will be necessary to look into the error codes.
> Error codes returned by OS X will need to go into
> forth.lab. (The error codes are the only system dependant part
> of forth.lab.) Then we will be pretty well set.
This is going to be a little tricky. Apple _really_ do not want us
mucking around with syscalls so this area is very poorly documented.
I can only give you the example of calling syscall fork. It was only
an afterthought I checked the other registers (ie, in this case EDX)
for return values that I found out what the heck was going on.
This already sort of proves that the low level syscalls need not
follow what's documented in the man 2 pages for the c equivalents.
I'll have a think and look at the released XNU source again, see if I
get any ideas, see if there's anything I missed. I'm pretty darn sure
the syscall return codes are undocumented.
The only way around this so far I have thought of is like the way I
did fork and OPEN-FILE. Basically trial until you find an error then
work around it.
Or call the c equivalents, which is really what apple want I think
(which is slightly more painful, meaning I have to preserve __LINKEDIT
probably).
I will in all likelihood improve upon the port, make it call c or
other dynamic libraries at some stage.
It would be nice to be able to throw up a GUI. So I'm thinking if I
can get this done, it may be even be multiplatformable ie if you call
something like GTK. I'm sure callbacks can be worked around somehow.
> There is a good chance that you can compiler programs with
> -c have you tried that?
> Like
> echo ': MAIN ." Hello world" CR ;' >h.frt
> xina -c h.frt
>
> The -g options is somewhat trickier, I guess.
Hmmm.. good. Found one bug already. The 5.37 forth.lab file has top
bit of that block and the previous block corrupted. I will go onto my
linux machine later and see if the file is similarly corrupted, if it
isn't, I'll build around it, or get an older forth.lab file and
improvise. I'll give it a bash. TURNKEY works well so I don't see why
this shouldn't work. Keep you posted.
> --
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- like all pyramid schemes -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=nhttp://home.hccnet.nl/a.w.m.van.der.horst
Robert Spykerman