Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!ames!ucbcad!ucbvax!jade!eris!mwm From: mwm@eris.UUCP Newsgroups: comp.sys.amiga Subject: Small C code (was: Portable "C" Code) Message-ID: <3008@jade.BERKELEY.EDU> Date: Thu, 2-Apr-87 12:35:04 EST Article-I.D.: jade.3008 Posted: Thu Apr 2 12:35:04 1987 Date-Received: Sun, 5-Apr-87 01:30:20 EST References: <8704020726.AA05684@cory.Berkeley.EDU> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Organization: Missionaria Phonibalonica Lines: 31 In article <8704020726.AA05684@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >Also, I've noticed that 32 bit ints don't really increase >code size all that much. What really makes the difference is the small >code and data model (using relative address for globals). > > -Matt Damn straight. By switching to small code/data and stripping the linked binary (or NODEBUG on blink), Lattice generates code that's less than 10% larger than MANX (assuming I've got the straight data on how big the MANX version of what I'm working on is correct). What peeves me is that the NODEBUG option for BLINK wasn't documented. I've got a paper by the Software Distillery people describing how to get small binaries out of Lattice. That's where I found out about NODEBUG. Applying most of the rest of it would break mg's portability to other things. BTW, Matt, exactly what makes writing software for both compilers so inherently ineffecient? Mg doesn't have much problems with that, though trying to stay portable to BSD Unix (first among many others) causes problems. Thanx,