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


Groups > comp.lang.misc > #11851

Re: SPL/3000 (was Re: Alternatives to C)

From Kragen Javier Sitaker <kragen@canonical.org>
Newsgroups comp.lang.misc, alt.folklore.computers
Subject Re: SPL/3000 (was Re: Alternatives to C)
Date 2026-08-28 21:13 -0300
Organization Primarily biological and memetic
Message-ID <87bjalbx78.fsf@debian> (permalink)
References (8 earlier) <rCOMR.3047$_v1.2327@fx21.iad> <87ecfjdr2m.fsf_-_@debian> <dJgkS.592$UGU.176@fx46.iad> <875x0udrqg.fsf@debian> <S9lkS.188322$A8R8.136869@fx35.iad>

Cross-posted to 2 groups.

Show all headers | View raw


scott@slp53.sl.home (Scott Lurndal) writes:
> The original HP-3000 was a stack-based architecture.  Very similar to the
> Burroughs B6500 (the successor to the B5500).  I believe that was emulated
> on later models based on the PARISC processors.   Arithmetic instructions
> all popped the operands from the stack and pushed the result.  No GPRs.

Yes, I believe you’re right.  But I had the impression that it had a
linear memory model like Unix (though segmented, like PDP-11 Unix), not
a descriptor-based memory model like the B6500.  I don’t know if that’s
really true.  The difference is that, on Unix, if you index off the end
of an array, you are likely to read or write some other variable instead
of getting a segfault, while on the B6500 the hardware checks the
bounds.

> SPL/3000 directly exposed the stack to the programmer via the TOS keyword.

Are there other things about the hardware that it exposed that C doesn't?

> <I haven't typed in the rest of the hardcopy listing yet...>

Whew!  That looks like a lot of work.  Plausibly current OCR technology
might be good enough?  You could try one of the big AI companies’ free
loss-leader websites, although myself I’ve been using duck.ai to
anonymize my requests a bit.

Kragen

Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Alternatives to C (was Re: Safety of casting from 'long' to 'int') cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 13:05 +0000
  Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-12 02:28 +0100
    Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 18:37 -0700
      Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-12 22:32 +0100
        Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') John Ames <commodorejohn@gmail.com> - 2026-05-12 15:28 -0700
          Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 02:49 +0200
        Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') scott@slp53.sl.home (Scott Lurndal) - 2026-05-12 23:21 +0000
          Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 02:53 +0200
            Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') scott@slp53.sl.home (Scott Lurndal) - 2026-05-13 14:15 +0000
              Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-13 12:30 -0700
                Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 20:20 +0000
          SPL/3000 (was Re: Alternatives to C) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-27 21:30 -0300
            Re: SPL/3000 (was Re: Alternatives to C) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-28 04:32 +0000
            Re: SPL/3000 (was Re: Alternatives to C) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-28 04:33 +0000
            Re: SPL/3000 (was Re: Alternatives to C) scott@slp53.sl.home (Scott Lurndal) - 2026-08-28 14:14 +0000
              Re: SPL/3000 (was Re: Alternatives to C) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-28 15:28 -0300
                Re: SPL/3000 (was Re: Alternatives to C) scott@slp53.sl.home (Scott Lurndal) - 2026-08-28 19:18 +0000
                Re: SPL/3000 (was Re: Alternatives to C) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-28 21:13 -0300
                Re: SPL/3000 (was Re: Alternatives to C) Lars Poulsen <lars@beagle-ears.com> - 2026-08-29 06:14 -0700
                Re: SPL/3000 (was Re: Alternatives to C) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-29 15:19 -0300
    Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-12 02:40 +0000
      Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-12 15:11 +0100
    Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-21 13:59 +0800

csiph-web