Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Thomas Koenig Newsgroups: comp.compilers Subject: Re: PALM challenge Date: Sun, 2 Oct 2022 20:13:42 -0000 (UTC) Organization: news.netcologne.de Lines: 19 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <22-10-011@comp.compilers> References: <22-10-001@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="74503"; mail-complaints-to="abuse@iecc.com" Keywords: architecture, history Posted-Date: 02 Oct 2022 20:58:29 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:3185 Steve Lewis schrieb: > Lots of new CPUs, sure. > > But let's explore an old CPU: the 1975 PALM. ... > [Architecture described here http://computermuseum.informatik.uni-stuttgart.de/dev/ibm_5110/technik/en/ > It doesn't look like it would be all that bad as a target for C although the code to handle the stack > might be a bit tedious. -John] Interesting having 16-bit integers but only an 8-bit ALU, where a carry for addition is added to the upper bit, would need a few instrucions for a 16-bit addtion. It would be straightforward to write out such an instruction sequence each time a 16-bit addition was required, though. [IBM programmed the PALM to simulate most of S/360 to run APL\360 and the System/3 mini to run the BASIC interpreter, both I assume hand coded in assembler. It was a tour de force at the time. I agree that generating code for C doesn't look hard, just tedious. -John]