cafl@lindy.stanford.edu (Carol Farlow Lerche) (04/12/91)
Could someone on this group post whether the small model limit is in the Coherent C compiler or in the operating system? If the former, has anyone tried to convert DOS .OBJ or .EXE files to whatever the native form under Coherent is? Or are compatible forms used?
winans@sirius.mcs.anl.gov (John Winans) (04/13/91)
In article <cafl.671471479@lindy> cafl@lindy.stanford.edu (Carol Farlow Lerche) writes: >Could someone on this group post whether the small model limit is in the >Coherent C compiler or in the operating system? If the former, has anyone >tried to convert DOS .OBJ or .EXE files to whatever the native form under >Coherent is? Or are compatible forms used? The whole memory model thing is more a culture than a restriction imposed by the compiler or the OS. But since the OS is in charge of maintaining the culture, I guess we could 'blame' the OS for it. They are not compatible. But what you probably really wanna know is by how much. And on that one I can only guess, but since I have written a few simple OS's, I would put a few $$$s on that they are using considerably different calling conventions when entering the kernel. In fact it would probaby faster to just re-write an application from scratch than to try to convert something even as simple-looking as XTREE than to try to convert it's binary or object file. This problem of dealing with foreign object files is the subject of the Inetl interface spec that is being outlined (or is now finished... I am not sure) as I type this. When finished, it will descripe linkage conventions in such a way that any OS can run any other OS's programs. I personally wish them luck on it. It will not be easy to account for EVERY nuance of EVERY OS that they wish to cover. So, the general answer is NO. But, if you wrote a chunk of code that used no OS services (rather difficult if you wish it to do anything.. like I/O or even terminate properly for that matter) It is just going to be 80286 code and as such would 'run' under Coherent. But you would have to write a program to translate the .OBJ (or whatever) into an a.out format. So in that case, the answer would be yes. (But keep in mind that you would not be able to use any of the standard lib code that came with the DOS compiler! And that means no access to stuff you probably take for granted in DOS like video ram access and com ports etc...) For these, you would probably have to write 'cap' routines to interface with Coherent's libs. Quite similar to the sort of stuff you have to write to deal with calling functions in foreign languages. This type of coding problem is usually too much trouble and causes time to be removed from one's life expectancy. ESPECIALLY if you are trying to convert a program for which you have no source!!! It is challenging, but perhaps the largest pain in the #&@%ing @$$ you will ever wanna deal with. Ofcourse I HAVE been wrong before, your mileage may very :) --John -- ! John Winans Advanced Computing Research Facility ! ! winans@mcs.anl.gov Argonne National Laboratory, Illinois ! ! ! !"The large print giveth, and the small print taketh away"-- Tom Waits !
lipka@lip.hanse.de (Michael Lipka) (04/25/91)
Most work in porting software to Coherent has to do with the small
memory model limitation of the Coherent's c-compiler. When I bought
the OS I thought I could solve that problem getting gcc running,- no
chance with 16 bit pointers.
But I'v heard of i286 XEN*X-sites that use gcc. There may be a
chance to cross-compile gcc (as far as I heard the limitation is only
with the compiler, not the assembler) on such a machine. Has anybody
thought about this or is working on it?
--
Michael Lipka, Buxtehude, Germany
--------------------------------------------------------------------
| I04LIP@DHHDESY3.BITNET | lipka@lip.hanse.de | lipka@mcshh.hanse.de
--------------------------------------------------------------------root@gbdata.hou.tx.us ((Gary Clark II)) (04/28/91)
Michael, The problems not with the C complier! It's in the kernel it self. When you the system, the protected mode of the 286 keeps you confined to 64k pretty much. You CAN use more, but only if you are running in supervisor mode and can play with a couple of the pointers(note this is under Coherent, when running things like xenix and SysV/AT the kernel plays with the pointers for you) This means that when writeing a device driver you can use more than 64k but really no place else, util they mod the kernel. Now I just wish they would give us atlest the option to generate 386 code for our programs.(you can use 32bit code in a 64k segment...) Does anyone disagree? Let me know. Gary -- Gary Clark II | Public Access Coherent System 713-364-9041 GB Data Systems | UUCP: !uhnix1!gbdata!root | root@gbdata.uucp Houston, Texas | INTERNET: postmaster@gbdata.hou.tx.us USA | Disclaimer: Why have one if they don't work?
gsm@mailgsm.mendelson.com (Geoffrey S. Mendelson) (04/28/91)
lipka@lip.hanse.de (Michael Lipka) asks: > >Most work in porting software to Coherent has to do with the small >memory model limitation of the Coherent's c-compiler. When I bought >the OS I thought I could solve that problem getting gcc running,- no >chance with 16 bit pointers. > >But I'v heard of i286 XEN*X-sites that use gcc. There may be a >chance to cross-compile gcc (as far as I heard the limitation is only >with the compiler, not the assembler) on such a machine. Has anybody >thought about this or is working on it? I have talked to the people at Mark Williams about this. The major problem is that the 808x,80186, and the 80286 all use 64k program segments. When Coherent was written, this was the way you did things. The compiler can only generate 64k segments. The linker can only generate 64k segments, and the kernal is designed to support 64k segments. As part of the 386 coherent project the compiler and linker were "fixed" to allow bigger (size not stated) segments. Either the 386 no longer has segments, or there is no longer the silly 64k limitation. I believe that a program on the 386 can be as long as there are bits to address it.(32?) Having a 386 compiler, linker and kernal does not mean that you have a saleable product. There are still too many unwanted and to few wanted features. I expect that 386 coherent will hit the streets next year, but that is only a guess. The idea of porting the 386 coherent compiler to 286 coherent has been discussed many times at Mark Williams. It seems that every time someone comes up with an easy way to do it (short of re-writing the Kernal), there is some hunk of code that can't work with that method. So it seems that we are stuck with the 128k (64k per segment) limit. If you want the unlimited program size of UNIX, I'm afraid you are going to have to buy unix. I don't know anything about Xenix, but I have a 386 system running ESIX unix across the room from my coherent system. Not only was it far more expensive, (386sx-16, 4meg ram 2x60m hard disks; bought at last summer's prices), plus the cost of ESIX (about $700), there is a large amount of system adminstration needed to keep a unix box running. Coherent is simple and easy by comparison. I'd rather live with the 64k segment limit. As a side note, I find that I have almost no trouble porting code that I wrote under Coherent to unix. There are some minor differences though. It's more like an early unix, an early BSD, and the developer's own ideas of an operating system thrown in a big pot and mixed slightly. I find the two following books to be a great help when programing for Coherent, I only resort to the man pages, or the manual if these fail me. UNIX Programmer's Quick Reference. By John Valley Que Corporation ISBN 0-88022-535-1 $7.95 us C The pocket Reference. By Herbert Schildt Osbone McGraw-Hill ISBN 0-07-881321-2 $5.95 ------ Geoffrey S. Mendelson geoffrey@mendelson.com (215) 242-8712
joachim@jrix.radig.de (Joachim Riedel) (04/28/91)
lipka@lip.hanse.de (Michael Lipka) writes: > Most work in porting software to Coherent has to do with the small > memory model limitation of the Coherent's c-compiler. When I bought > the OS I thought I could solve that problem getting gcc running,- no > chance with 16 bit pointers. > > But I'v heard of i286 XEN*X-sites that use gcc. There may be a > chance to cross-compile gcc (as far as I heard the limitation is only > with the compiler, not the assembler) on such a machine. Has anybody > thought about this or is working on it? XENIX 286 runs also on AT/286-machine. But it uses the Large Memory-Model, (Compiler option -MLe) so programs can be larger than 64 kb. There are some restrictions in comparison to what a 386-UNIX is able to. But when gcc works with XENIX/286 you can't assume to get it working with Coherent. Also XENIX is SysV R.2 (unless you have a copy of the old stuff). Joachim PS: Du kannst dich ja mal melden, wenn du Fragen hast. +---------------------------------------+-------+-------------------+-------+ | Joachim Riedel | @ @ | Don't worry, | @ @ | | Geschwister-Scholl-Strasse 48 | \_/ | keep smiling | \_/ | | D-6050 Offenbach am Main +-------+-------------------+-------+ | Tel. +49 69 85 62 25 | joachim@jrix.radig.de | +---------------------------------------+-----------------------------------+
joachim@jrix.radig.de (Joachim Riedel) (04/28/91)
joachim@jrix.radig.de (Joachim Riedel) writes: >lipka@lip.hanse.de (Michael Lipka) writes: >> Most work in porting software to Coherent has to do with the small >> memory model limitation of the Coherent's c-compiler. When I bought >> the OS I thought I could solve that problem getting gcc running,- no >> chance with 16 bit pointers. BTW: The small model is not the limitation of the compiler it is the limitation of whole Coherent. No segment can be larger that 64 k and Data and Stack share the same segment. Joachim