In article
<94cdc3ff-fc7f-495a-acdb-83c1319f0a09@[EMAIL PROTECTED]
>,
Robert Spykerman <robert.spykerman@[EMAIL PROTECTED]
> wrote:
>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.
Using elf solves some problems, using native formats solves
probably more problems.
<SNIP>
As I have some notes, that are more or less independantly readable,
I snipped the rest of the article. If I would phrase the remainder
as responses it would become hard to read, I think.
1.
Indeed it is true that some assemblers mandate certain
sections.
In general there is a trick to get rid of unwanted sections
afterwards: the strip command. I had to do that for nasm,
especially in behalf of SAVE-SYSTEM.
2.
If the .data section works for the kernel part of xina, that is
fine. I'm slightly surprised that it is executable.
A test to do is the following:
0 PREV !
This will change a variable in the kernel, and would bomb out
if the kernel was implemented in a classic .text section.
3.
What you experience with large executables is the issue I
mentioned with sections not to be written to the disk image.
A "nowrite" section (or whatever it is called in Your Favorite
Assembler) cannot contain code or data. Instead it defines
a layout of memory, so only pointers into it are of interest.
These pointers are known to the program at large, and are filled
in by the relocating linker where they are referenced in other
sections.
An example may clarify this. The stacks are in unitialised memory.
The initial value of a stack pointer is a fixed place there.
This must be a known address to the kernel. You don't want
a 64 Mbyte stack in the disk image, and there is no initialised
data there, so this is a candidate for a nowrite section.
4.
You want the initialised and the unitialised part of Forth
to be in that order, and without a gap.
This is the default way a sensible linker handles this
if the unitialised section follows the kernel in the source,
but there is no guarantee, especially not over different OS's.
The official way is to use linker scripts.
Also default linking will select a start address for you.
For some reason a normal start address in linux32 is around
HEX 0804,0000 and on linux64 it is HEX 0000,0060,0000,000.
You don't want to think about where to find documentation
to select a reasonable address here. It certainly takes more
time to then porting to linux64 has take me now ;-).
I have some experience with linker scripts in GNU (for embedded
work) and it is an issue to avoid if at all possible.
5.
If the changes of OSX compared to linux are as small as it looks now,
I will certainly add OSX as an option to the generic system, with its
own configuration file osx.cfg.
Then you can generate tailor made pdf, html and info documentation
for osx (for the kernel at least).
6.
The generic system can spit out Intel code palatable for gas,
and *even the old gas code with the operands reversed*
(before the ".Intel_syntax prefix" directive).
If that is the way to go, so be it. It is clear that I will get
to be more involved to start that up.
I'm indebted to the authors of nasm, as I used it for
years for the main versions, even building the Windows versions
on linux. But gas delivers the same advantage to me as gcc
for gforth, it allows me to port to other processors easily.
The port to AMD64 was a few evenings work thanks to that.
(I wished they would at least allow the standard ; for comment,
instead of #, though.)
7.
There is nothing wrong with looking into the output of the
c-compiler. The -S option is your friend. I do that a lot.
It doesn't really entitle you to the information you get,
but at least it is correct.
(It wears off. The most simple code on linux64, only
issuing a write system call and static linking, generates
600 kbyte of assembler.)
8.
Apple moving the numbers of syscalls around? Hmm. They
would certainly create a lot of trouble for themselves
and their customers, not the least that no old executable
would run. Not all hope is lost, even then.
The generic system contains c-code to steal those (and other)
constants from the c-compilation system. It is called stealconstant.c.
It is system-dependant, and must be run - of course - on the system
whose constants you want to steal.
>
>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
|
