EOAHMAD%NTIVAX.BITNET@cunyvm.cuny.edu (12/21/90)
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.
zseelunnon@qut.edu.au (12/25/90)
In article <39781@nigel.ee.udel.edu>, EOAHMAD%NTIVAX.BITNET@cunyvm.cuny.edu writes: > > 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. Minix ST and presumably all the other 68K compilers use the same relocation table, this is the same as the TOS executable relocation table, however the files header is different. I think there is a header file that describes the format somewhere. I wrote a program once to turn TOS headers into minix headers, it was not very difficult. PS. on this note does anyone offhand know if Minix ST's symbol table is stored the same way as in TOS ie last in the file where the bss would be ??? > 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. This is not the whole issue here neither the ST or 68K amigas or Macs have any relocation hardware AT ALL. When a process forks the programs data space is physically swapped by the CPU and the text restarted for the child or parent. This is a massive overhead. Fortunately most programs exec soon after they fork so this does not happen too often. Read all about it in the manual bit describing the shadowing process. In the PC it is a matter of changing a couple of segment registers. If .EXE's were to be adopted then some way to systematically handle lots of text,data and stack segments would be required in the PC version with the same attendant disadvantages :-( > 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. However I sort of second this, the use of coff may well help in implementing dynamic or shared libraries and other good bits, but it will not help break the 64K limit on PC's persay. It would however be a little more universal,(my commercial compiler generates COFF :-) BOB R.Lunnon@qut.edu.au ZSEELUNNON@qut.edu.au