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

    From Kragen Javier Sitaker@3:633/10 to All on Fri Aug 28 15:28:39 2026
    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

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Scott Lurndal@3:633/10 to All on Fri Aug 28 19:18:10 2026
    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...>

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Kragen Javier Sitaker@3:633/10 to All on Fri Aug 28 21:13:31 2026
    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

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Lars Poulsen@3:633/10 to All on Sat Aug 29 06:14:25 2026
    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

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Kragen Javier Sitaker@3:633/10 to All on Sat Aug 29 15:19:52 2026
    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

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)