Newsgroups: comp.os.minix
Subject: Re: C++ compiler
References: <8dagjg$204q$1@cti15.citenet.net> <xlfog6lqpgh.fsf@wintermute.informatik.uni-tuebingen.de> <uhj*RPkro@news.chiark.greenend.org.uk> <8f5fip$19l$1@nnrp1.deja.com>
Organization: Rochester Institute of Technology, Rochester, NY
From: aje9383@osfmail.isc.rit.edu (Andrew Erickson)
NNTP-Posting-Host: grace.isc.rit.edu
X-Original-NNTP-Posting-Host: grace.isc.rit.edu
Message-ID: <3916fb0c@news.isc.rit.edu>
Date: 8 May 2000 13:36:12 -0500
X-Trace: 8 May 2000 13:36:12 -0500, grace.isc.rit.edu
Lines: 98
XPident: aje9383
X-Original-NNTP-Posting-Host: 129.21.4.100
XPident: Unknown
Path: news.adfa.oz.au!clarion.carno.net.au!news0.optus.net.au!news1.optus.net.au!optus!intgwpad.nntp.telstra.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.mathworks.com!newsfeed.nyu.edu!news-nysernet-16.sprintlink.net!news.sprintlink.net!news.isc.rit.edu!aje9383
Xref: news.adfa.oz.au comp.os.minix:35241

In article <8f5fip$19l$1@nnrp1.deja.com>, Bit-Man  <bitman2@my-deja.com> wrote:
>Hi Minixers,

<snip>

>Now straight to the point, there are three options that were being
>depicted:
>
>1.- Adapting C++ compiler to Minix
>2.- Using a C++ to C converter
>3.- Cross-compiling
>
>As a matter of fact I must present my apologies because in the previous
>messages I wrote GCC when C++ compiler must be wrote (for generality
>sake). I'm trying to look at the forest without loosing the tree (or
>something in the style).
>
>Option #1 was the most widely discussed, ranging from "build the
>swapping INTO GCC?" to "Write an emulator for 16 bit I+D execution of a
>simple 32 bit stack machine (SSM) which pages code from one file (name
>of code file from linked name to the emulator), and pages data memory to
>a temporary file." (thanks "thedebategod" and "Fred J. Scipione"). Thew
>most important problem with these is that a lot of code must be run in
>user mode to support them (thanks "Martijn van Buul" and "Markus Leypold
>"), and it's really very slow and complicated because it must support
>many functions that the kernel doesn't support (and once again in
>userland).

In other words, invent a 32-bit P-machine.  (The P-machine was a simple
8-bit stack machine which UCSD pascal was implemented on.  This allowed
quick ports of UCSD pascal to random systems, but the results were slow
when compared with native compilation.  I speak from (somewhat limited)
experience with Apple Pascal.)  Since GCC is not particularly fast, one
would expect this approach to be barely usable for software development
on older machines--and that's the only class of machines for which this
would be necessary.  It's nice from an academic point of view, but....

>The option #2 was cleaner than #1 but as "Bob Solomon" suggested "I
>would guess that #2 could be a mythical person years work, if possible
>at all ... c++ is a much bigger language that c." Ditto.

Are there any availiable for porting?  I know that several of the early
C++ compilers were just C++ to C translators and a truckload of library
files.  (Perhaps they descended form the AT&T/Bell Labs C++ compiler?)

Additionally, a converter would (presumably) require less core than one
big compiler program would.

>Option #3 is also cleaner than #1. It simply takes the compilation and
>linking process out of Minix-STD, doing it in other OS and transferring
>the binaries to Minix-STD.

The other operating system could very well be Minix-386 or Minix-68K or
Minix-ARM or Minix-PPC or Minix-Alpha or...

I guess I tend to think of Minix-STD as encompassing everything that is
not Minix-VMD, including e.g. MacMinix.  Only the older Intel processor
architectures have the very tight memory requirements.

>Despite the method chosen there's a limit and is the 16 bit I+D space
>for executing Minix programs (64KB limit for code, data and stack). The
>problem in #1 and #3 is not with the porting or cross-compiling per se,
>but with this limit (many times in this thread has been said that is
>very difficult to put a C++ program in 64 KB). Modestly, I think that we
>must be able to use more than 64KB in a program, so we can make an
>extension to the actual model (or a new model, the one that less
>interferes and most benefits Minix) that allows Minix the use of more
>than this, prior to migrate a C++ compiler to Minix.

I suspect you may need more to simply run a (non-trivial) compiled C++
program.  Because of this, another possibility seems fairly obvious to
me:  simply fail to support C++ on the 8086/80286.  This is hardly the
first time something like that has happened--there are already several
programs which lack support on Minix-86 but work on other versions.

>Honestly this idea came to my brain suggested by William McBrine
>comment: "since ACK is finally going to be available for hacking, I was
>wondering -- is it really necessary to be restricted to the small
>(single-code-segment, single-data-segment) model?"
>
>I think that we must divide this in two tasks: one for a new execution
>model and other for C++ compiler migration to Minix. In this way each
>group will concentrate its efforts in a task with sharply defined
>objectives, each people can work in the most
>comfortable/easy/experience related one (or both), both task can be
>carried out in parallel, etc. (a lot of advantages as you see).

One fairly easy thing would be to have separate stack and data segments.
As I understand it, this would not break any ANSI C spec, although some
programs might break (which assume more than the spec gives them).  For
anything more substantial, I suspect you'd need quite a bit of new work
in the compilers.  (I'm certainly no expert on the minutae of the 8086,
though, so I may very well be mistaken.)

-- 
Andrew Erickson
I don't buy stuff from canned meat products.  I also don't buy stuff from
mass e-mail sendings.
