Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!texbell!bigtex!rena!kogwy!ccut!s.u-tokyo!hideki
From: hideki@is.s.u-tokyo.ac.jp (YOSHIDA Hideki)
Newsgroups: gnu.gcc
Subject: Re: more 8086 ideas
Message-ID: <308@utsun.s.u-tokyo.ac.jp>
Date: 4 Dec 89 05:44:37 GMT
References: <8911301314.AA17358@wubios.WUstl.EDU>
Sender: news@s.u-tokyo.ac.jp
Reply-To: hideki@is.s.u-tokyo.ac.jp
Organization: Dept. of Information Science, the Univ. of Tokyo, Japan.
Lines: 24
In-reply-to: david@WUBIOS.WUSTL.EDU's message of 30 Nov 89 12:14:56 GMT

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