Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!helios.ee.lbl.gov!pasteur!ucbvax!bloom-beacon!bu-cs!mirror!frog!john
From: john@frog.UUCP (John Woods)
Newsgroups: comp.lang.c
Subject: Re: malloc impossible?
Message-ID: <1363@X.UUCP>
Date: 18 Jan 89 03:35:00 GMT
References: <19@xenlink.UUCP> <225800106@uxe.cso.uiuc.edu> <310@twwells.uucp> <9384@smoke.BRL.MIL>
Organization: Servants of the Great White Frog
Lines: 23

In article <9384@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:
I> In article <1010@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes:
n> >> One can imagine a machine with different spaces for each different
t> >> intrinstic data type, where malloc() has to select from one of 8
e> >> or 16 possibilities.  Of course, since malloc() gets only one argument,
r> >> it has no way to decide which address space to use.
p> >Wow. Wouldn't structs be *really* interesting on a machine like this?
r> 
e> Don't worry, unless all those spaces are "shadowed", C cannot be
t> implemented on it.

Actually, the real solution to such a problem is to write a PDP-11 simulator
in the native machine code, and use a PDP-11 compiler for the newly-produced
virtual machine.  The ANSI spec doesn't DEMAND that floating-point operations
use any available floating point hardware, does it?

If an architecture is going to be that bizarre, C is not necessarily going to
be the language of choice for it.
-- 
John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101
...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu

Go be a `traves wasswort.		- Doug Gwyn