Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #235420 > unrolled thread
| Started by | Kragen Javier Sitaker <kragen@canonical.org> |
|---|---|
| First post | 2026-08-28 15:28 -0300 |
| Last post | 2026-08-29 15:19 -0300 |
| Articles | 5 — 3 participants |
Back to article view | Back to alt.folklore.computers
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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
| From | Kragen Javier Sitaker <kragen@canonical.org> |
|---|---|
| Date | 2026-08-28 15:28 -0300 |
| Subject | Re: SPL/3000 (was Re: Alternatives to C) |
| Message-ID | <875x0udrqg.fsf@debian> |
scott@slp53.sl.home (Scott Lurndal) writes: > Kragen Javier Sitaker <kragen@canonical.org> writes: >>scott@slp53.sl.home (Scott Lurndal) writes: >>> Those clever people _were_ cranking out suitable systems languages by >>> the bucketful. (...), HP-3000 SPL (Systems Programming Language - I >>> used SPL in the late 70s) > > With the caveat that I last used it a half century ago, I'd call it > a bit lower level (closer to the hardware) than C. It is tailored > around the stack-based HP-3000 architecture. As the HP3000 architecture > was influenced by ex-Burroughs large systems engineers, it is closer > to Burroughs ALGOL-based system languages than C. That’s interesting — that wasn’t apparent from the parts of the manul I glanced over. (I hope that doesn’t sound like I doubt you!) The HP 3000 didn’t do memory security the way the B5000/B5500 did, did it? With segment descriptors granting fine-grained access to memory, like CHERI today? I had the impression that it was a relatively conventional 16-bit mini except for having an instruction set that was a more convenient compile target — more like the HP 9825 than like the Burroughs 5500. What did SPL do to expose the hardware that C doesn’t do? That’s exactly the kind of insight I was hoping for when I saw your post! It’s difficult to extract such informtion from language manuals. Kragen
[toc] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-28 19:18 +0000 |
| Message-ID | <S9lkS.188322$A8R8.136869@fx35.iad> |
| In reply to | #235420 |
Kragen Javier Sitaker <kragen@canonical.org> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Kragen Javier Sitaker <kragen@canonical.org> writes:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Those clever people _were_ cranking out suitable systems languages by
>>>> the bucketful. (...), HP-3000 SPL (Systems Programming Language - I
>>>> used SPL in the late 70s)
>>
>> With the caveat that I last used it a half century ago, I'd call it
>> a bit lower level (closer to the hardware) than C. It is tailored
>> around the stack-based HP-3000 architecture. As the HP3000 architecture
>> was influenced by ex-Burroughs large systems engineers, it is closer
>> to Burroughs ALGOL-based system languages than C.
>
>That’s interesting — that wasn’t apparent from the parts of the manul I
>glanced over. (I hope that doesn’t sound like I doubt you!) The HP
>3000 didn’t do memory security the way the B5000/B5500 did, did it?
>With segment descriptors granting fine-grained access to memory, like
>CHERI today? I had the impression that it was a relatively conventional
>16-bit mini except for having an instruction set that was a more
>convenient compile target — more like the HP 9825 than like the
>Burroughs 5500.
>
>What did SPL do to expose the hardware that C doesn’t do? That’s
>exactly the kind of insight I was hoping for when I saw your post! It’s
>difficult to extract such informtion from language manuals.
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.
An application would be PREPared (linked) to various system
and language libraries at runtime (very similar to Unix dynamic shared
objects). The HP-3000 memory management was segment based (not page based)
and the segmented libraries would be shared at runtime by all applications
that used those libraries (subject to the segments being rolled out to
slower storage (e.g. disk) make space for other users of the multiprogramming
executive (MPE)).
SPL/3000 directly exposed the stack to the programmer via the TOS keyword.
There are a bunch of manuals here:
<https://bitsavers.org/pdf/hp/3000/>
Here's the first part of the SOO application (Son Of Overlord) which monitors system
utilization (must be run with the capability to access the MCP memory).
$TITLE "SON OF OVERLORD (SOO)"
$CONTROL USLINIT,NOWARN,MAP,CODE
$CONTROL SEGMENT=SOO
BEGIN << OUTER BLOCK >>
<< .......MODIFICATIONS TO THIS SOURCE FILE........ >>
<< ................................................ >>
<< >>
<< 04-28-77 PCBSTAT NOW DELETES ENTRIES FOR PROCESSES THAT
ARE WAITING ON THEIR FATHER.
04-28-77 THE WORDING FOR THE CHANGE LIST WAS MODIFIED TO
REFLECT THE FACT THAT THE CHANGE LIST DENOTES
CHANGES IN THE STATUS LIST AND NOT THE PROCESSES
THEMSELVES.
06-01-77 A COLUMN WAS ADDED TO THE RIGHTHAND SIDE OF
THE OUTPUT TO INDICATE THE TYPE OF PROGRAM FILE
BEING EXECUTED, I.E. IF THE FILE WAS A SON OF MAIN
THE WORD "MAIN" WOULD PRINT, IF A SON OF MAIN
IS USING PROCESS HANDLING, AND HAD CREATED A SON,
THE WORK "USON" WOULD PRINT, THUS SHOWING THE
SOURCE OF THE EXECUTION OF THE PROGRAM.
AN ADDITIONAL LINE IS PRINTED IF A PROCESS HAS
EXTRA DATA SEGMENTS, SHOWING THE SIZE OF THE DATA
SEGMENT.
THE DATA SEGMENT SIZE COLUMN WAS CHANGED TO PRINT
IN BYTES, NOT WORDS.
THE DATE AND TIME LINE WHICH PRINTS ON THE BATCH
OUTPUT OF SOO HAS BEEN ENLARGED TO PRINT IN NORMAL
DATE.HOUR.MIN.SEC.MILL FORMAT.
AN EXTERNAL PROCEDURE HAS BEEN ADDED, NAMED
DATELINE, TO INTERFACE WITH THE COMPILER LIBRARY
ROUTINE.
CODE WAS DELETED TO NO LONGER DELETE FROM PRINTING
PCB'S WHICH HAD THE "LIVE" FLAG SWITCHED OFF. IN THIS
WAY THE DATA STACK SIZE WILL APPEAR EVEN IF THE
PROCESS IS NOT IN CONTENTION FOR CPU USAGE.
THE PRIORITY NUMBER OF THE PROCESS HAS BEEN ADDED
WHICH SHOWS ITS VALUE AS OF THE TIME OF THE SNAPSHOT
TAKEN BY SOO.
IF PCB(4).(12:1) IS ON(INDICATING A RUNNING CONDITION)
AN '*' IS PRINTED AFTER THE PRIORITY NUMBER.
THE PROCESS'S MEMORY RESIDENCY FLAG IS PRINTED.
IN A BATCH RUN, THE WAIT WORD(PCB(4) IS PRINTED
IN LITERAL FORM TO INDICATE THE REASON FOR THE
PROCESS BEING IN A WAIT STATE.
THE INITIAL DESIGN REASONING FOR THE PROGRAM HAS BEED
ALTERED, SOO WAS ORIGINALLY MEANT TO DISPLAY ONLY
THOSE ITEMS WHICH WERE IN CONTENTION FOR MEMORY
RESOURCES. tHIS VERSION, HOWEVER PRINTS NOT ONLY
MEMORY RESOURCE INFO AND CPU UTILIZATION INFO, BUT
ALSO GIVES SOME INFO WHICH ALLOWS A CURSORY ANALYSIS
OF THE REAL/VIRTUAL RATION(SEE ALSO "TUNER2" FROM
BERNIE STALEY IN ST. LOUIS. THE USE TO WHICH THIS
INFO WAS PUT WAS TO TRY TO SIMULATE A "MONITOR" TYPE
SITUATION ON THE FLY IN AN ENVIRONMENT WHICH
WOULD NOT ALLOW MONITOR TO RUN(BLOCK MODE TERMINAL
I/O).
C A U T I O N *********************************************
SOO CANNOT BE RUN WHILE MONITOR IS RUNNING. SOME
VERY FUNNY THINGS HAPPEN!!!!!!!!!!!!
C A U T I O N *********************************************
A HOME UP LINE WAS ADDED TO THE PROCEDURE CHANGEPRINT
IN ORDER TO COPE WITH THE MULTI-SCREEN DISPLAYS WHICH
NOW PRINT AS A RESULT OF THE INCLUSION OF ADDITIONAL
LINES OF DATA.
$PAGE
<<***** DECLARATIONS *****>>
EQUATE
MAXPCB=50, << MAX ALLOWABLE PCB IN SYSTEM >>
MAXCHANGE=10, << MAX NUMBER OF CHANGES DURING ONE STATUS >>
WORDS'STATUS=24, << NUMBER OF WORDS IN A STATUS ENTRY >>
WORDS'CHANGE=24, << NUMBER OF WORDS IN A CHANGE ENTRY >>
STATUSLISTLEN=WORDS'STATUS*MAXPCB, << LENGTH OF A STATUS LIST >>
CHANGELISTLEN=WORDS'CHANGE*MAXCHANGE, << LENGTH OF A CHANGE LIST >>
DEFINE
ENABLE = ASSEMBLE(PSEB)#,
DISABLE = ASSEMBLE(PSDB)#,
DSTMOVE = ASSEMBLE(MFDS 4)#;
DEFINE
VERS="01"#, << J PODKOMORSKI 6/1/77 ROLLING MEADOWS >>
BLANK=B(0):=" "; MOVE B(1):=B(0),(79)#,
BLANK'130=B(0):=" "; MOVE B(1):=B(0),(129)#;
INTEGER
PRIORITY, << THE PRIORITY NUMBER OF THE PROCESS >>
RUNNING, << THE RUNNING FLAG OF THE PROCESS >>
PTYPE, << TYPE OF PROCESS, 2=CI,1=SOM,0=SOS >>
XDS'SUB, << SUBSCRIPT FOR XDSTAB >>
MEM, << WHETHER OR NOT THE PROC IS IN MEMORY >>
HIGHLITELEN, << LENGHT OF HIGHLITE MESSAGE >>
LEN, << LEN OF STRING INPUT FROM TERMINAL >>
QM4=Q-4, << USED TO GET INITIAL PAUSETIME >>
MAXPCB,
PERCENTCPU,
PAUSETIME,
MODE,
CURPCB, << VALUE OF THE PCB BEING SCANNED CURRENTLY >>
NEXTCHANGE, << NEXT AVAILABLE CHANGELIST ENTRY >>
TERMTYP, << TERMINAL TYPE >>
I, << TEMP LOOP VARIABLE >>
TEMP, << TEMP LOCATION >>
STACKSIZE, << SIZE IN WORDS OF THE STACK FOR CURPCB >>
CONTROLYCOUNT, << COUNT OF THE TIMES THE USER HAS MASHED CY >>
INPUTFNUM, << INPUT FILE MPE FILE NUMBER >>
OUTPUTFNUM; << OUTPUT FILE MPE FILE NUMBER >>
LOGICAL
WAIT, << THE WAIT FLAGS FROM PCB >>
FIRSTTIME, << TRUE THE FIRST STATUS LOOP >>
HPTERM, << TRUE IF THE TERMINAL FOR OUTPUT IS AN HP >>
INTERACTIVE; << TRUE IF BOTH INPUT AND OUTPUT IS TO A TERMINAL >>
<<
CHANGELIST AND STATUS LIST CONTAIN ENTRIES WHICH HAVE:
1) A DOUBLEWORD
2) A 26 CHARACTER STRING
3) A 18 CHARACTER STRING
PART 2 IS ALWAYS A FILE NAME WHILE PART 3 IS ALWAYS A
USER NAME. PART 1 IS A PROCESS CPU TIME FOR STATUSLIST
AND FOR CHANGELIST ITS 0 OR 1 FOR A PROCESS TERMINATION
OF STARTUP.
>>
INTEGER ARRAY
XDSTAB(0:3), << TABLE OF EXTRA DATA SEG SIZES >>
CHANGELIST(0:CHANGELISTLEN), << INFO FOR EACH CHANGE >>
STATUSLIST(0:STATUSLISTLEN), << INFO FOR EACH PCB >>
BYTE ARRAY
ONEBLANK(0:0), << ONE BLANK ASCII CHARACTER >>
INPUTFNAME(0:10), << INPUT FILE NAME >>
OUTPUTFNAME(0:10), << OUTPUT FILE NAME >>
ERRORBUF(0:79), << BUFFER FOR ERRORS >>
F(0:25), << BUFFER FOR ONE FILE NAME >>
U(0:16), << BUFFER FOR ONE USER NAME >>
F'(0:25),
U'(0:16),
HIGHLIGHT(0:8), << HOLDS THE HP TERMINAL HIGHLIGHT SEQUENCE >>
LOGONU(0:16), << LOGON USER ID >>
SUBQUEUE(0:0), << >>
JS(0:0), << >>
BCHANGELIST(*)=CHANGELIST,
BSTATUSLIST(*)=STATUSLIST;
DOUBLE
STACK'BYTES, << SIZE OF STACK IN BYTES, NOT WORDS >>
OLDTOD, << PLACE TO SAVE THE OLD TIME OF DAY >>
CURTOD, << TIME OF DAY FOR THE CURRENT STATUS REPORT >>
ITTCOUNT, << CURRENT ITERATION NUMBER >>
MAXITTCOUNT, << LAST ITERATION >>
CPUTIME, << PROCESS TIME FOR THE CURRENT PCB >>
TEMPTIME; << TEMP SAVE FOR ONE OF THE TIMES >>
DOUBLE ARRAY
DCHANGELIST(*)=CHANGELIST,
<I haven't typed in the rest of the hardcopy listing yet...>
[toc] | [prev] | [next] | [standalone]
| From | Kragen Javier Sitaker <kragen@canonical.org> |
|---|---|
| Date | 2026-08-28 21:13 -0300 |
| Message-ID | <87bjalbx78.fsf@debian> |
| In reply to | #235421 |
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
[toc] | [prev] | [next] | [standalone]
| From | Lars Poulsen <lars@beagle-ears.com> |
|---|---|
| Date | 2026-08-29 06:14 -0700 |
| Message-ID | <116ulvj$38h27$1@dont-email.me> |
| In reply to | #235421 |
On 2026-08-28 12:18, Scott Lurndal wrote: > Kragen Javier Sitaker <kragen@canonical.org> writes: ... >> That’s interesting — that wasn’t apparent from the parts of the manul I >> glanced over. (I hope that doesn’t sound like I doubt you!) The HP >> 3000 didn’t do memory security the way the B5000/B5500 did, did it? >> With segment descriptors granting fine-grained access to memory, like >> CHERI today? I had the impression that it was a relatively conventional >> 16-bit mini except for having an instruction set that was a more >> convenient compile target — more like the HP 9825 than like the >> Burroughs 5500. ... > > SPL/3000 directly exposed the stack to the programmer via the TOS keyword. > > There are a bunch of manuals here: > > <https://bitsavers.org/pdf/hp/3000/> > > Here's the first part of the SOO application (Son Of Overlord) which monitors system > utilization (must be run with the capability to access the MCP memory). Unfortunately, at a cursory glance it seems that the excerpt quoted is all comments and declarations, so it does not show anything that turns into executable code. So we have not seen how the language is close to the stack architecture. -- Lars Poulsen - an old geek in Santa Barbara, California
[toc] | [prev] | [next] | [standalone]
| From | Kragen Javier Sitaker <kragen@canonical.org> |
|---|---|
| Date | 2026-08-29 15:19 -0300 |
| Message-ID | <8733vw94c7.fsf@debian> |
| In reply to | #235447 |
Lars Poulsen <lars@beagle-ears.com> writes: > On 2026-08-28 12:18, Scott Lurndal wrote: >> There are a bunch of manuals here: >> <https://bitsavers.org/pdf/hp/3000/> > > Unfortunately, at a cursory glance it seems that the excerpt quoted is > all comments and declarations, so it does not show anything that turns > into executable code. > > So we have not seen how the language is close to the stack architecture. Take a look at things like <https://bitsavers.org/pdf/hp/3000/spl/30000-90025_System_Programming_Language_Textbook_197709.pdf#page=75> to get more of the flavor of the language. Unlike our honorable correspondent Scott Lurndal, I don’t have any experience with it, but it looks very Algolish. Kragen
[toc] | [prev] | [standalone]
Back to top | Article view | alt.folklore.computers
csiph-web