Path: utzoo!attcan!uunet!lll-winken!xanth!mcnc!decvax!ima!esegue!johnl From: johnl@esegue.uucp (John Levine) Newsgroups: comp.lang.c Subject: Re: Memory Models Summary: a necessary evil Message-ID: <1989Aug14.163909.9920@esegue.uucp> Date: 14 Aug 89 16:39:09 GMT References: <5653@ficc.uu.net> <309@hitech.ht.oz> <19158@usc.edu> Reply-To: johnl@esegue.UUCP (John Levine) Followup-To: alt.flame Organization: Segue Software, Cambridge MA Lines: 48 In article <19158@usc.edu> blarson@basil.usc.edu (bob larson) writes: >In article <309@hitech.ht.oz> clyde@hitech.ht.oz (Clyde Smith-Stubbs) writes: >>From article <5653@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva): >>>> [near and far pointers are] not a C language issue. It's kludgery >>>> introduced specifically in the IBM PC environment. >>It IS a language issue - you could argue that near and far address spaces >>are not part of the Standard C, therefore it is not a C issue, however >>there are sufficient architectures that REQUIRE a useful language to >Just because your address space is segmented dosn't mean you have to >kludge your language around. Prime C does quite nicely without memory >models. ... I am probably one of the few people in the world to have had the dubious pleasure of writing an assembler for the Prime, intended to be the back end for a C compiler that never saw the light of day. The Prime address space is only sort of segmented, because some instructions and address formats pay attention to segment boundaries and some don't. The C compiler wherever possible uses the latter set, so the segmentation is more or less invisible at the architecture level. (Well, not quite, the address mode you have to use to get to the stack is segmented, so the stack frame for any single procedure is limited to slightly under one segment. Don't even think about alloca.) I also note that since the word-addressed Prime was unable to reference characters in a reasonable way they added some new instructions specifically for the benefit of the C compiler that load characters, store characters, and increment character pointers, which of course means that Prime's customers whose machines predate the new instructions are unable to run C programs. Great. The '86 architecture, all its innumerable faults notwithstanding, has quite consistent memory addressing. The segments are really there, and from other extensive experience (I did most of the Prime assembler in Turbo C at home!) I can testify that large model C code is much larger and slower than small model, so you really need to have some sort of address space hackery to write useful programs. Sad, but true. What I would really like to see is a data declaration language that lets you take advantage of segments rather than just tolerating them, e.g. group useful data into segments, map structures into segments in interesting ways, pass segment handles around. Never seen one. Even Multics PL/I just kludged it. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 {ima|lotus}!esegue!johnl, johnl@ima.isc.com, Levine@YALE.something Massachusetts has 64 licensed drivers who are over 100 years old. -The Globe