Recent discussions about specification of sections and linking
of lina on linux and xina on OSX set me thinking and experimenting.

I declared with emphasis that the normal sections are unusable for Forth,
not being executable or not being writable.

However, because the .text .data and .bss sections are special, they
are known to the linker and may be treated as special by the linker.
They do! It turns out that there is a linker flag, that makes the code
section writable. It is the -N or --omagic flag. At least it is
supported by the GNU loader.

With this option we can put the kernel in the .text section.
The .bss can be used to define the layout of the free dictionary
space, such as where the tib is, block buffers and stack space.
It doesn't follow, that code assembled here can be executed, but
on linux it apparently does, at least as far as my experiments go.
This doesn't interfere with the SAVE-SYSTEM as used in lina at all.
Also ``lina -c hello.frt'' generates an executable.
I have implemented this in my latest beta.

On Apr 13, 2:21 pm, Albert van der Horst
wrote:

As you probably realize, Albert, OS X unfortunately does not use the
standard ld linker.

Recapping the discussions with Josh on patching privileges on the mach
header so that the __TEXT and __DATA segments are rwx (it, of course,
works) - I found that a bit inconvenient after a few reassembles.

It turns out the linker has a 'rarely used' option -segprot

In article c19g2000prf.googlegroups.com>,
Robert Spykerman gmail.com> wrote:

...

On Apr 13, 9:49 pm, Albert van der Horst
wrote:
...snip...

Well, there's an Apple as with the gcc that came with Xcode 3.0. I'm
pretty sure this gas is under version 2.0 from memory. ( and I believe
the gcc is 4.0 but I'm not able to check at the moment). It did not
correctly identify the intel operand sequence directive.

Apple also to their credit provided an apple nasm (0.98). The main
difference of this apple version to the late 'common' versions of 0.98
is that it knows how to assemble mach-o .o's.

I built nasm 2.02 on OS X - it also appears to know mach-o's. But
given that Apple has not provided it, until I fully understand it I am
currently using the Apple one - I don't notice any significant
differences, to be quite honest.

The gas file bombs spectacularly, if I recall it was mainly because of
the lack of the intel syntax directive...

In article w8g2000prd.googlegroups.com>,
Robert Spykerman gmail.com> wrote:

Don't waste your time trying. The .intel syntax is progress.
Old format is not applicable to 5.

On Apr 16, 4:09 pm, Albert van der Horst
wrote:
..

LOL.

Anyways, right now I'm trying to port the SYSTEM word.

The fork syscall appears to work (I get another forth instance on top
of the old one) but the shell does not get called to do say, something
quick like "ls" SYSTEM. I changed the vector to the apple one, maybe
there's a difference. I also had to patch waitpid - it's wait4 on the
apple.

On Apr 16, 6:08 pm, Robert Spykerman gmail.com>
wrote:

...

Just a brief update re: my attempt at porting Albert's ciforth to OSX

I've found out what appears to be the problem afflicting my current
attempt at porting the SYSTEM word.

It would seem that the fork syscall appears to return the PID to both
parent and child process which results in the child not knowing it's a
child (because it would expect a PID of zero) and hence execution
pretty much waits there.