Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!umd5!zben From: zben@umd5.umd.edu (Ben Cranston) Newsgroups: comp.sys.mac.programmer Subject: Re: Segmentation (was Re: ARRGH (Strings and things)) Summary: Segments are for large, transitory functions Message-ID: <5569@umd5.umd.edu> Date: 2 Nov 89 17:21:58 GMT References: <16004@netnews.upenn.edu> <8835@hoptoad.uucp> <16420@dartvax.Dartmouth.EDU> <8852@hoptoad.uucp> <14386@well.UUCP> <8878@hoptoad.uucp> Reply-To: zben@umd5.umd.edu (Ben Cranston) Organization: University of Maryland, College Park Lines: 60 In article <88528@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > [Apple says] you should put all function-pointer fetching > routines into the main code segment: that way, they will be jump table > pointers. This may work fine for code that uses one or two function > pointers and calls them all itself. However, just imagine passing a > function pointer into the jump table to the vertical retrace manager or > as a completion routine to the file manager. Can you say "intermittent > crash when A5 is not CurrentA5"? I knew you could. Segments should be used for large, transitory functions like initialization, disk prepping, making an environment up from scratch the first time a user calls the application, etc. They should not be used for vertical retrace tasks or IO completion tasks unless the birth, life, and death of these tasks take place entirely while control is contained in that segment > And imagine code (if you must; I don't have to imagine) that has lots > of function pointers -- you're going to move *all* assignments to them > into the main code segment? I don't think so! The alternative, termed 'Jedi' by Tom Lippincott in message <1989Nov1.204513.1183@agate.berkeley.edu>, would be for the development system to ALWAYS use jump table pointers for references to functions, even when the caller is within the same segment as the callee. It's only a few cycles, but it is a cost. > And as recently pointed out by another poster, you have yet another > potential intermittent error if traps glue happens to be in an unloaded > segment. This has the same replicability problems as the others. The same diatribe for traps glue: it should be in the main segment unless it is ONLY used by routines within a single segment, in which case it can safely be linked with that segment. Come on. The Unisys 1100 system, written in the 1960s for crying out loud, AUTOMATICALLY moved shared routines up the segment tree as far as possible. Yet the same people who term that machine a dinosaur have to manually place their library routines. It would be funny if it were not so pathetic. On that machine I was once bitten very badly COMPARING function pointers when one was redirected through the jump table and the other was not. I ended up having to temporarily place those functions back in the main segment until I reprogrammed all the code to use an integer index, and a case at the very end when the functions were actually being called. We seem to have two extremes, neither one of which is terribly useful: Tim is saying "segments are too bothersome, I can't be bothered to actually *design* a segmentation scheme, instead I'll make the users of my programs buy enough physical memory not to need it". Others are saying "put everything into segments and beat on the development systems manufacturers to make everything actually *work* in segments: function pointers, IO completion routines, VBL tasks, traps glue, etc". My claim is that segmentation can be a useful technique to reduce the memory requirements of applications. In order to use it effectively you have to THINK about what you are doing. I don't see a lot of that in the hacker environment. -- Sig DS.L ('ZBen') ; Ben Cranston * Computer Science Center Network Infrastructures Group * University of Maryland at College Park