Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!ucbvax!agate!eris!mwm From: mwm@eris.berkeley.edu (Mike (I'm in love with my car) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Re: Another question on the 80286- er, 68000 memory models Message-ID: <10507@agate.BERKELEY.EDU> Date: 3 Jun 88 04:57:40 GMT References: <8805182223.AA20918@cory.Berkeley.EDU> <2653@louie.udel.EDU> <2869@polya.STANFORD.EDU> <2069@sugar.UUCP> Sender: usenet@agate.BERKELEY.EDU Organization: Missionaria Phonibalonica Lines: 57 In article <2069@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: <> * data addressing. This can either be 32-bit absolute <> or 16-bit relative. *Pointers are 32-bits in either <> case*. <* code addressing (jsr's.) These can either be 32-bit <> absolute or 16-bit relative. Again, you can mix <> models. < * int size. Both Manx and Lattice allow 16 and 32-bit <> ints. < < 4) Manx did a half-assed implementation of the X3J11 draft: no < function prototyping. When they wake up and put it in then the < whole thing will become a non-issue. Lattice did a quarter-assed job. They got function prototypes into 4.0. They also got hooks in to generate calls to libraries inline, instead of through a stub, and tied the latter to the former in their distributed files. If you ask for prototypes, you get the inline code. They could be seperated, but who would not either one of them? It's not clear that the "models" on the 68000 should be called "models". After all, you can mix code from between all the models without too much trouble. This isn't really true on the intel processors.