david@WUBIOS.WUSTL.EDU (David J. Camp) (11/30/89)
Here are a couple of additional problems one will face with an 8086 port of gcc. I am not familiar with the algorithms of gcc, but it may be impossible to make it figure out how to use 16-bit instructions. One way around this is to write an assembler macro package to emulate some 32-bit instructions (e.g. 386 instructions). Then have gcc generate macro calls. Another problem is the use of memory models. It is probably best to restrict the port to the large or huge model at first, since the smaller models are only required for time and space efficiency. I do not know enough about the gcc inctruction description language to say, but perhaps these macros could be implemented there instead of as a separate package. Also, I do not know what gcc expects that the assembler will expect, but you may need to do special coding to handle the Microsoft Assembler and its expectations, or port the gnu assembler to the 8086. These constraints and those described in my earlier message have convinced me to give up on this project for the time being. I do think it would be very desirable to have gcc able to generate code for MS-Dos, because that would immediately allow many Unix utilities to be ported to messy dos. -David- Bitnet: david@wubios.wustl ^ Mr. David J. Camp Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics uucp: uunet!wucs1!wubios!david v 660 South Euclid Washington University (314) 36-23635 Saint Louis, MO 63110
bschwart@elbereth.rutgers.edu (some great stormfowl, whenever he has walked his while) (12/03/89)
In article <8911301314.AA17358@wubios.WUstl.EDU> david@WUBIOS.WUSTL.EDU (David J. Camp) writes: >I do think >it would be very desirable to have gcc able to generate code for MS-Dos, >because that would immediately allow many Unix utilities to be ported to >messy dos. I would like to see a gcc port to Misery DOS simply because I enjoy using gcc. At the very least a port to 286 Xenix. (Nope, I don't have Xenix, but if someone wants to donate the cash for me to get it then I will not hesitate. I _do_ have a 286, so that's no problem.) I'd like to mention, however, that Microsoft C 5.1 and QuickC do a good job of compiling UN*X stuff with minimal change, in my experience. I have had less luck with Turbo C or Zortech C. (Here's a warning, though: if you buy QuickC 2.0, when you open the package you will find a note asking you for another $25 to get printed manuals. As distributed, QuickC 2.0 comes with a couple of skimpy books and an online hypertext manual. Deception and trickery. More reason to prefer gcc.) -- Barry Schwartz, Chief SAPsucker bbs@cdspr.rutgers.edu Grad Student, Dept. of Elec. and Comp. Engg. bschwart@elbereth.rutgers.edu Rutgers University College of Engg. bbs@hankel.rutgers.edu Piscataway, NJ 08854 U.S.A. rutgers!cdspr!bbs
hideki@is.s.u-tokyo.ac.jp (YOSHIDA Hideki) (12/04/89)
In article <8911301314.AA17358@wubios.WUstl.EDU> david@WUBIOS.WUSTL.EDU (David J. Camp) writes: >Here are a couple of additional problems one will face with an 8086 port >of gcc. I am not familiar with the algorithms of gcc, but it may be >impossible to make it figure out how to use 16-bit instructions. One >way around this is to write an assembler macro package to emulate some >32-bit instructions (e.g. 386 instructions). Then have gcc generate >macro calls. Another problem is the use of memory models. It is >probably best to restrict the port to the large or huge model at first, >since the smaller models are only required for time and space >efficiency. Each code/data segment of 8086 is limited to 64KB. This makes porting of GCC to large/huge model very hard. Porting using only small model goes around this problem, but I think this implementation would not be so useful. --- Hideki Yoshida Department of Information Science Faculty of Science The University of Tokyo hideki@is.s.u-tokyo.ac.jp