Path: utzoo!telly!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!WUBIOS.WUSTL.EDU!david
From: david@WUBIOS.WUSTL.EDU (David J. Camp)
Newsgroups: gnu.gcc
Subject: more 8086 ideas
Message-ID: <8911301314.AA17358@wubios.WUstl.EDU>
Date: 30 Nov 89 12:14:56 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 25

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


Brought to you by Super Global Mega Corp .com