Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #235428
| Path | csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail |
|---|---|
| From | Kragen Javier Sitaker <kragen@canonical.org> |
| Newsgroups | comp.lang.misc, alt.folklore.computers |
| Subject | Re: SPL/3000 (was Re: Alternatives to C) |
| Date | Fri, 28 Aug 2026 21:13:31 -0300 |
| Organization | Primarily biological and memetic |
| Lines | 26 |
| Message-ID | <87bjalbx78.fsf@debian> (permalink) |
| References | <10su8cn$am9i$1@dont-email.me> <10tof8a$b63$1@dont-email.me> <10tp26r$1l93l$21@dont-email.me> <10tpt9j$c3i4$1@dont-email.me> <10tpvqv$ivo$3@reader1.panix.com> <10ttvng$1j579$1@dont-email.me> <10tu082$1irrv$2@kst.eternal-september.org> <10u069d$285sv$1@dont-email.me> <rCOMR.3047$_v1.2327@fx21.iad> <87ecfjdr2m.fsf_-_@debian> <dJgkS.592$UGU.176@fx46.iad> <875x0udrqg.fsf@debian> <S9lkS.188322$A8R8.136869@fx35.iad> |
| MIME-Version | 1.0 |
| Content-Type | text/plain; charset=utf-8 |
| Content-Transfer-Encoding | 8bit |
| Injection-Date | Sat, 29 Aug 2026 00:15:53 +0000 (UTC) |
| Injection-Info | dont-email.me; logging-data="2972766"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/WfLoS/IP0+bWDZc32FoV/"; posting-host="19c753fba95970cf1a99e4804f17687c" |
| User-Agent | Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
| Cancel-Lock | sha1:048eQODXl7bIS4bg4sRrLEJqT2U= sha1:g64xM7JsKvTodjffzXgtLBkhukY= sha256:NWaTBo8vXHJFyDwHCB0BTTfaosrys/w9UGEgarOUnFI= sha1:dy9lQIu5GyJHEGGnRI1+NVOxYFg= sha256:uOY0YStPyjG4LAyDGBfP2ZwFjJDIbe0daI6ZaR7/A/c= |
| Xref | csiph.com comp.lang.misc:11851 alt.folklore.computers:235428 |
Cross-posted to 2 groups.
Show key headers only | 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 alt.folklore.computers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web