Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!mmdf
From: EOAHMAD%NTIVAX.BITNET@cunyvm.cuny.edu
Newsgroups: comp.os.minix
Subject: minix 386 loader
Message-ID: <39781@nigel.ee.udel.edu>
Date: 21 Dec 90 09:22:21 GMT
Sender: mmdf@ee.udel.edu
Lines: 31


       PILLAY.KDA%EXETER.AC.UK@pucc.princeton.edu mentioned that
>To have such a loader under Minix, you have to find out what the
>ACK compiler produces as relocatable code. The rest is pretty straight

Actually ACK compiler for 8086 class microprocessors does not give any
relocation information, but Minix for ST and Amiga do have but I do not know
what scheme they use. I had sent out mails asking for information but nobody
replied in detail. One told me that ST uses the same format as TOS but Alan
(Edinburg) told me that Minix uses its own relocation format. None
of the Minix people working on the Minix ST and Amiga C compilers replied.
        Shouldn't they look into using a standard object file format instead
of creating different ones for each different microprocessors. The reason
why relocation information is important for 68000 is that it is
equipped with address translation whereas 8086 has a rudimentary one in its
segmentation unit which limits the program size to 64K only. If Andy had used
MSDOS EXE file format, the 64K barrier can easily be broken, just as the ST
and AMIGA.
        The segmentation size for 80386 is 4 G but only in protected mode.
The loader need not process any relocation information, instead it must
initialise the 386 memory management as to the new base address and
privileges.
        To write the loader for EXE or other object code format such as
COFF(Common Object Code Format- the proposed standard for object code format),
is easy as Pillay had pointed out, but to persuade the compiler to generate the
relocation information in the right format is not. GCC for 386 does not have
the relocation information because it is designed for true Unix which
requires dedicated memory manager.
        Since Andy is against the support for Virtual Manager, may be
it is time to develop a common software approach such as the adoption of
the COFF as the object format for all Minix compilers.