Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.misc > #11851
| 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.
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
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