Re: PALM challenge

Thomas Koenig <tkoenig@netcologne.de>
Sun, 2 Oct 2022 20:13:42 -0000 (UTC)

          From comp.compilers
Related articles
PALM challenge lewissa78@gmail.com (Steve Lewis) (2022-10-01)
Re: PALM challenge gah4@u.washington.edu (gah4) (2022-10-01)
Re: PALM challenge tkoenig@netcologne.de (Thomas Koenig) (2022-10-02)
Re: PALM challenge gah4@u.washington.edu (gah4) (2022-10-03)
| List of all articles for this month |
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.compilers
Date: Sun, 2 Oct 2022 20:13:42 -0000 (UTC)
Organization: news.netcologne.de
References: 22-10-001
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

Steve Lewis <lewissa78@gmail.com> 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]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.