Hello -
I work with Aesec, and the GEMSOS operating system from our subsidiary Gemini Computers. GEMSOS is a high assurance security kernel running on the x86 architecture. We have been using 16-bit and 32-bit versions of the MetaWare Professional Pascal compilers using Compact memory model. GEMSOS uses a fully segmented memory system - segments are used to model / instantiate protected security objects in the the system.
We use the MetaWare compiler in a cross compiler configuration, hosting it on a Unix SysVr3 system. Linux IBCS lets us run it on Linux, at least in 32-bit mode.
The kernel of the OS runs in 16-bit mode and exports a 32-bit interface. Applications and services outside the security kernel run in 32-bit mode, with full 48-bit addressing and 32-bit offset support, so that segments are not limited to 64KB. I think we impose a 2GB limit on segment sizes.
I'd like to migrate from the no-longer supported MetaWare compilers to something else. Free Pascal looks like a good candidate.
I see you're working on an i8086_msdos target support for the compiler (
http://wiki.freepascal.org/DOS). You support the compact memory model.
At present we use COFF, but would like to migrate to ELF, provided I can create a suitable ABI profile to meet our needs. We use run-time intersegment linkage to allow far calls between segments using destination segment entry point symbols, which is why we can get by with Compact model near pointers for calls. We provide our own intersegment linkage that hides the far calls from the developer.
I wonder if you believe it would be practical for me to extend that support to provide what amounts to an i386_gemsos (or i486_ or i586_) version, perhaps using gemsos as the system name in lieu of msdos to allow me to handle any binary interface issues I need to for backward compatibility with the MetaWare compilers - for example, they produce a SEG_12 (COFF) relocation entry for the 16-bit segment selector offset in static pointer storage (.data and .bss of COFF) to enable load/run-time dynamic linking of object files.
We use modules in MetaWare, which looks like it should map reasonably well to facilities you support.
We would like to improve our intersegment linkage to use a more natural set of tools - probably modeled on DLLs and ELF GOTs - for separate code segments.
I have already adapted (trivially) the GNU binutils gas and ld to recognize and deal with the SEG_12 relocation entries, and am able to routinely use gas and ld to create our COFF binaries.
So - my question for you has to do with whether you or anyone else has ever expressed interest in extending the DOS memory model support to support 48-bit pointers (16 bit segment selector + 32-bit offset), or does it sound like too large an effort to be worthwhile?
My understanding of the support we would require would include:
1) use 48-bit pointer storage for all data pointers, including any pointers stored in static (.data, .bss, etc.) areas, passed as parameters on the stack, stored as dynamic variables in stack frames, or returned as pointer function return values;
2) create a relocation reference in produced object file for the segment selector of static data storage locations, particularly those requiring run-time initialization
3) ability to specify the storage segment for static data declarations (MetaWare uses pragmas to do this, but other mechanisms would be fine).
Regards,
Ed Reed
Edit: revised Subject for clarity