Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!necntc!necis!mrst!sdti!mjy
From: mjy@sdti.UUCP (Michael J. Young)
Newsgroups: comp.lang.c++
Subject: Re: C++ for Intel 286??
Message-ID: <175@sdti.UUCP>
Date: Thu, 12-Nov-87 16:27:37 EST
Article-I.D.: sdti.175
Posted: Thu Nov 12 16:27:37 1987
Date-Received: Sun, 15-Nov-87 10:04:21 EST
References: <4800003@uiucdcsm> <1539@unicus.UUCP>
Reply-To: mjy@sdti.UUCP (0000-Michael J. Young)
Organization: Software Development Technologies, Sudbury MA
Lines: 59

In article <1539@unicus.UUCP> emc@unicus.COM (Eric M. Carroll) writes:
>
>I too am interested in the state of 80x86 C++ compilers currently on the
>market. I have this vague, and likely unfounded, hope that the one of
>the two C++ compilers that I know of (Lifeboat and Guidelines) would
>hide the entire near/far pointer problem from the C++ code. I was
>thinking that cfront could be set up to select which pointers to use and
>issue the correct C with near/far keywords. Can anyone inform me of what
>these manufacturers have in fact done with this problem? 

I'm not really familiar with the Lifeboat port, but Guidelines did not
put any of the extra keywords (e.g., near, far, cdecl) into the language.
They provide a bunch of batch files, each of which compiles source in
a different memory model (small, medium, compact, large, huge).  The
only change in the batch files is which "szal" file is given to cfront
for determining size and alignment information.  The C compiler is then
called with the appropriate memory model switches.  Unless you need to
do mixed-model programming, their approach is sufficient.

We recently ported cfront to OS/2 without difficulty.  However, writing C++
programs for OS/2 is the only time I've ever regretted not having the extra
keywords:  all OS/2 system calls must declared as pascal procedures.  In
this case, I've created C functions that hide the OS/2 calls, and do
everything else in C++.  Since the standard c-library functions all work
anyway, there aren't too many places where this is necessary.

>Finally, I have heard of subtle incompatabilites between cfront and pcc
>when dealing with pure C code. Does a list of known gotchas exist?

We were told by Dr. Stroustrup that 286 pcc-based compilers have a bug
in large model (which we use most often) which makes it almost impossible
to port cfront to 286 boxes that rely on pcc.  He gave us a simple test
case:


int *alloc();
int kl()
{
	int s;
	char *am;
	(am == 0) ?
		(am = (char *) alloc((long) s)):
		0;
}

If the above code successfully compiles in large model, you're home free.
Pcc-based 286 compilers (ours included) die with an internal compiler
error (register allocation error).  Unfortunately, this type of construct
is frequently generated by cfront.

I've been informed that the latest release of Metaware's High-C compiler
doesn't have this problem.  I don't have their compiler, so I can't verify
it.  Anyway, if you're going to use cfront on a 286 Unix box, I recommend
you consider alternatives to pcc.
-- 
Mike Young - Software Development Technologies, Inc., Sudbury MA 01776
UUCP     : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy
Internet : mjy%sdti.uucp@harvard.harvard.edu      Tel: +1 617 443 5779
"What would you do with a brain if you had one?" -- Dorothy, Wiz of Oz