Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #3179 > unrolled thread

PALM challenge

Back to article view | Back to comp.compilers

Contents

  PALM challenge Steve Lewis <lewissa78@gmail.com> - 2022-10-01 01:24 -0700
    Re: PALM challenge gah4 <gah4@u.washington.edu> - 2022-10-01 17:09 -0700
    Re: PALM challenge Thomas Koenig <tkoenig@netcologne.de> - 2022-10-02 20:13 +0000
      Re: PALM challenge gah4 <gah4@u.washington.edu> - 2022-10-03 04:37 -0700

#3179 — PALM challenge

Lots of new CPUs, sure.

But let's explore an old CPU: the 1975 PALM.

I'm looking for anyone interested to explore the idea.   Maybe prove how
robust modern tools are at adapting C, by exploring this ancient instruction
set.

You won't find much about this instruction set.  But, we've found an internal
IBM documentation about it.  We have an emulator for it.  And we have an
assembler for it.

I'm no expert about this process, hence seeking help.  From what I understand,
the instruction set has 4 tiers of 32 registers.  Each tier is an interrupt
level.   In Level 0, the first register holds the program counter (and the
second register is reserved as a branch target for certain branch
instructions- other than that, I think the registers are all fair game).
There are no Index registers, and no Overflow/Underflow registers (that I'm
aware of).   There is a special instruction for accessing some Devices (so
retaining the option for some inline assembly would good - these may be
necessary for keyboard and screen output).  In total it is approximately 45
instructions.

-Steve
[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]

[toc] | [next] | [standalone]

#3182

On Saturday, October 1, 2022 at 12:16:25 PM UTC-7, lewi...@gmail.com wrote:
> Lots of new CPUs, sure.

> But let's explore an old CPU: the 1975 PALM.

> I'm looking for anyone interested to explore the idea. Maybe prove how
> robust modern tools are at adapting C, by exploring this ancient instruction
> set.

My favorite for adapting C to new (or old) hardware is LCC.

You only have to rewrite the code generator, and it has a code generator
generator to make it easier.  The usual case, as with many Unix C
compilers, is to write out assembly code, and feed it to an assembler.

Since you already have an assembler, it should be pretty fast.

[toc] | [prev] | [next] | [standalone]

#3185

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]

[toc] | [prev] | [next] | [standalone]

#3188

On Sunday, October 2, 2022 at 5:58:33 PM UTC-7, Thomas Koenig wrote:

(snip)
> 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.

The small ALU was usual at the time.  The 360/30 and 360/40 both
have an 8 bit ALU, but implement the usual 32 bit S/360. It just
takes more microinstructions, and so more time. They even
implement the S/360 double precision 64 bit hexadecimal
floating point with that 8 bit ALU.

The 360/20 has a four bit ALU that only can add or subtract 1.
Binary or BCD 4 bit arithmetic is done in a microcode subroutine
loop, which is then called to implement larger operations.
It includes the full S/360 decimal instruction set, with up to 31
digit operands, including multiply and divide. But no 32 bit
binary instructions and no floating point.

As well as I know it, the ALU runs parity all the way though, so given
two 8 bit operands plus parity, it generates the 8 bit sum, or other
operation, with parity.

> [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]

The description I thought I remembered was, instead of interpreting
the user level instructions, like usual for microcoded machines,
they are compiled into microcode.  If you have a microcode subroutine
call instruction, you write the code for the larger operations once,
and then call the micro-subroutine.
[Pretty sure the 5100 didn't do that due to its modest speed and memory.
There are certainly modern JIT translators.  Apple's Rosetta works that way.
Fun fact: 360/30 long floating divide took 1.6ms and I don't mean us. -John]

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web