Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!mcvax!unido!tub!uwbln!ckl From: ckl@uwbln.UUCP (Christoph Kuenkel) Newsgroups: comp.lang.c Subject: Re: Memory Models Message-ID: <1719@uwbull.uwbln.UUCP> Date: 16 Aug 89 16:06:56 GMT References: <5653@ficc.uu.net> <309@hitech.ht.oz> <19158@usc.edu> <1989Aug14.163909.9920@esegue.uucp> Distribution: comp Organization: UniWare GmbH, Berlin Lines: 25 In article <1989Aug14.163909.9920@esegue.uucp>, johnl@esegue.uucp (John Levine) writes: > 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. I see it the other way round. Its true and fine. My expirience was with Zilogs Z8000. I always tried to compile and load my programs using the small (unsegmented in their notion) model and the result were astonishing quick programs. This was in the early days of the M68000 and the 68000 was quite uninteresting compared to the Z8000 (which was some years older as far as i know) due to this effect. When there were problems coming up, I switched to the segmented mode with a compiler flag and anything was fine. No language kludgery%. to me its a feature! christoph % except for static objects larger than 64k. but in contrast to the x86, large objects were allocatable via malloc. -- # includeChristoph Kuenkel/UniWare GmbH Kantstr. 152, 1000 Berlin 12, West Germany ck@tub.BITNET ckl@uwbln {unido,tmpmbx,tub}!uwbln!ckl