Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: gah4 Newsgroups: comp.compilers Subject: Re: fledgling assembler programmer Date: Fri, 24 Mar 2023 14:17:44 -0700 (PDT) Organization: Compilers Central Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <23-03-012@comp.compilers> References: <23-03-001@comp.compilers> <23-03-002@comp.compilers> <23-03-003@comp.compilers> <23-03-007@comp.compilers> <23-03-008@comp.compilers> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="85353"; mail-complaints-to="abuse@iecc.com" Keywords: assembler, C Posted-Date: 24 Mar 2023 18:44:04 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com In-Reply-To: <23-03-008@comp.compilers> Xref: csiph.com comp.compilers:3414 On Friday, March 24, 2023 at 7:10:00 AM UTC-7, Thomas Koenig wrote: (snip about the lost art of small memory compilers.) > On the Internet, there is a project for almost everything - in this > case Tiny C, which still seems to be under active development. Or > at least there are sill commits at https://repo.or.cz/w/tinycc.git . > However, there is a reason why compilers got so big - there is > always a balance to be struck between comilation speed, compiler > size and optimization. When I was writing the above, I was looking at the Program Logic Manual for the OS/360 Fortran G compiler. (G means it is supposed to run in 128K.) Fortran G was not written by IBM, but contracted out. And is not (mostly) in assembler, but in something called POP. That is, it is interpreted by the POP interpreter, with POPcode written using assembler macros. Doing that, for one, allows reusing the code for other machines, though you still need to rewrite the code generator. But also, at least likely, it decreases the size of the compiler. POP instructions are optimized for things that compiler need to do. I also had the source to that so many years ago, but not the manual describing it. > An extreme example: According to "Abstracting Away the Machine", the > very first FORTRAN compiler was so slow that the size of programs > it could compile was limited by the MTBF of the IBM 704 of around > eight hours. I remember stories about how well its optimizer worked, when it was believed that they had to compete in code speed with experienced assembly programmers. I don't remember anything about how fast it was. > The balance has shifted over time, because of increasing computing > power and available memory that can be applied to compilation, > and because relatively more people use programs than use compilers > than ever before. So, in today's environment, there is little > incentive for writing small compilers. I first thought about this, when reading about the Hercules project of an IBM S/370 emulator, and couldn't run gcc in 16MB. (Well, subtract some for the OS, but it still wouldn't fit.) > Also, languages have become bigger, more expressive, more powerful, > more bloated (take your pick), which also increases the size > of compilers. OK, the IBM PL/I (F) compiler, for what many consider a bloated language, is designed to run (maybe not well) in 64K. At the end of every compilation it tells how much memory was used, how much available, and how much to keep the symbol table in memory.