[Fwd: Re: Trying to work around a 16-bit x86 weirdness]

[Willem Duinker <wduinker at xs4all dot nl>]

-------- Original Message --------
Subject: 	Re: Trying to work around a 16-bit x86 weirdness
Date: 	Tue, 21 Oct 2003 20:52:06 +0200
From: 	Willem Duinker <wduinker@xs4all.nl>
To: 	Bernd Jendrissek <berndfoobar@users.sourceforge.net>
CC: 	DJ Delorie <dj@redhat.com>, gcc@gcc.gnu.org
References: 	<20031020084455.GA19425@prism.co.za> 
<200310202019.h9KKJYE31081@greed.delorie.com> 
<20031021060445.GA1642@prism.co.za> 
<200310211253.h9LCrVb30562@greed.delorie.com> 
<20031021144334.GA7709@prism.co.za>



To all interested in i86 (8086,80186)

I have over the last two months ported the old 2.7 version of DJ Delorie 
to the current 3.3.1 version. I  am willing to share the i86.x files if 
anybody is interested. Next to all the syntax changes from 2.7 to 3.3 I 
have added to the md-file things which where really needed like a tablejump.

I have tested the compiler on an embedded AMD186 system with a MSDOS 
like OS (made by a German firm BECK). It works nice for data movements 
etc. I created a crt0.S using the NASM example. As a libc I use an 
assorted set of subroutines. Most important to get a complete 
development chain (gcc, NASM,DJlink) was to create a library-tool (I 
call it DJlib) to support the right linker format.

Having read the discussion about the PSI mode, I would like to extend 
the files to a real far model for pointers. Having looked at the mn10200 
port this should be very do-able.

I think this could also help the ELKS people, since they seem to still 
rely on the old BCC compiler. I was up till my own coding relying on the 
HITECH dos pacific compiler.

Willem Duinker

Bernd Jendrissek wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, Oct 21, 2003 at 08:53:31AM -0400, DJ Delorie wrote:
>  
>
> > > > Have you looked at my old i86 port?  I don't expect it to work with
> > > >        
> > > Yes, most of the machine description is snarfed from your port.
> > >      
> > Ah, cool.
> >
> >    
> >
> > > (I did the i86.h and i86.c pretty much from scratch, though, as a sort
> > > of learning exercise.  I was surprised to see it attempting to work!)
> > >      
> > I think if I were to revisit that port, I'd do it completely
> > differently anyway.  I'd break out AH/AL etc as separate registers,
> > and use register pairs for HImode.  That way, QImode operations can
> > use the AH etc registers too (if the base reg is HImode, it will only
> > use AL).
> >    
>
> That sounds smart...  Maybe I can have my cake and eat it; I could
> always do it later.  Or I can hope that register allocation becomes
> *really* smart by the time myour port shapes up so it can use
> non-consecutive registers as pairs.  (Maybe it's done already??)
>
>  
>
> > > Seeing that I snarfed i86.md's contents from yours, it must be your bug!
> > > :)
> > >      
> > Hence the "I don't expect it to work with current sources" disclaimer.
> >    
>
> Strangely, it *broke* sometime last week.  It *used to* work.  I used to
> be able to compile my test program completely, and the only sillyness I
> had was moving constants through regs into memory.
>
> If I get desperate I'll start undoing my work and going back to previous
> CVS GCC's to find the place where it all goes pear-shaped.
>
> bernd
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE/lUX4/FmLrNfLpjMRAgJsAKCjTvZPNXyFDll5n+3rQjzNeJo5JACdG6xF
> Yi3Ga7z0GYqaGAueiG8wol0=
> =/DW9
> -----END PGP SIGNATURE-----
>
>
>