Path: utzoo!utgpu!watmath!att!dptg!rutgers!cmcl2!phri!marob!cowan
From: cowan@marob.masa.com (John Cowan)
Newsgroups: comp.lang.c
Subject: Re: Varargs problem
Message-ID: <24FC0BD3.4529@marob.masa.com>
Date: 30 Aug 89 16:31:13 GMT
References: <4YxPuc200VsnE_B3Jy@andrew.cmu.edu> <1301@levels.sait.edu.au> <10863@smoke.BRL.MIL>
Reply-To: cowan@marob.masa.com (John Cowan)
Organization: ESCC,  New York City
Lines: 26

In article <10863@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>On a true segmented architecture, for example, it might take more bits
>to represent a function address than for any data address within a task,
>because function pointers would have to include segment identification
>while with proper C compiler implementation all the process's data
>would be in a single known segment.


I realize I may be starting a flame war here, but what is supposed to count
as a "true" segmented architecture?  I immediately concede that the 8086 doesn't
have such a thing, but I contend that the 80286 running in protected mode does.
It has segment tables, segment length control, etc. etc.

Nevertheless, "far" object pointers are still necessary on such an architecture
if a process is allowed to access more than 64K of data.  Even on the '386,
where segments are allowed to be up to 4G, The Day Will Come, My Friends, when
processes routinely need more than that!  Back to "far" pointers.

Perhaps there is some clever compiler technology that allows one to have more
bytes in a segment than the processor architecture allows, but if so, I can't
imagine what it might be.
-- 
Internet/Smail: cowan@marob.masa.com	Dumb: uunet!hombre!marob!cowan
Fidonet:  JOHN COWAN of 1:107/711	Magpie: JOHN COWAN, (212) 420-0527
		Charles li reis, nostre emperesdre magnes
		Set anz toz pleins at estet in Espagne.