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

Groups > comp.lang.misc > #11784 > unrolled thread

Alternatives to C (was Re: Safety of casting from 'long' to 'int')

Back to article view | Back to comp.lang.misc

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.

Contents

  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

Page 1 of 2  [1] 2  Next page →

#11784 — Alternatives to C (was Re: Safety of casting from 'long' to 'int')

In article <10tpt9j$c3i4$1@dont-email.me>, Bart  <bc@freeuk.com> wrote:
>On 10/05/2026 05:39, Janis Papanagnou wrote:
>> [snip]
>> What makes you think that I'd need to write an own language given that
>> there's a plethora of languages of all kinds and paradigms existing.
>
>So where's the one that works like mine?

I mean, Rust does exactly what you were just describing.

>And why are there so many new ones still appearing? Most of them you 
>will not know about.

Consider the possibility that you may be unique in the world in
possessing the combination of requirements and aesthetic
judgement that makes you feel you need a language like yours.

As for new languages, there are a number of reasons.  Most of
them are not particularly relevant here.

At this point, you may consider doing what Keith suggested, and
moving further discussion of your language to comp.lang.misc.
Here, I'll start by cross-posting to that group for you.

	- Dan C.

[toc] | [next] | [standalone]

#11785

On 10/05/2026 14:05, Dan Cross wrote:
> In article <10tpt9j$c3i4$1@dont-email.me>, Bart  <bc@freeuk.com> wrote:
>> On 10/05/2026 05:39, Janis Papanagnou wrote:
>>> [snip]
>>> What makes you think that I'd need to write an own language given that
>>> there's a plethora of languages of all kinds and paradigms existing.
>>
>> So where's the one that works like mine?
> 
> I mean, Rust does exactly what you were just describing.

Rust could hardly be more different than mine.

>> And why are there so many new ones still appearing? Most of them you
>> will not know about.
> 
> Consider the possibility that you may be unique in the world in
> possessing the combination of requirements and aesthetic
> judgement that makes you feel you need a language like yours.

My language fills the same niche that C does.

I don't have much of a problem with the things that C can do, but with 
how it does it, its syntax, its ancient baggage, its quirks, its 
folklore, its Unix-centric ecosystem, its pointless UBs, its insistence 
in working with every oddball processor, its solving every shortcoming 
with macros, its adherents who will defend every misfeature to the death...

Maybe the answer is to just create my own language?! I did exactly that, 
and didn't to have to deal with C for 10-15 years, but you can't get 
away from it because it's everywhere.

It is also frustrating looking at C forums and people thinking they are 
too stupid to grasp something when it's language that could have been 
better.

> As for new languages, there are a number of reasons.  Most of
> them are not particularly relevant here.
> 
> At this point, you may consider doing what Keith suggested, and
> moving further discussion of your language to comp.lang.misc.

Sure, a pretty much dead group.

[toc] | [prev] | [next] | [standalone]

#11786

Bart <bc@freeuk.com> writes:
[...]
> I don't have much of a problem with the things that C can do, but with
> how it does it, its syntax, its ancient baggage, its quirks, its
> folklore, its Unix-centric ecosystem, its pointless UBs, its
> insistence in working with every oddball processor, its solving every
> shortcoming with macros, its adherents who will defend every
> misfeature to the death...

You're mostly wrong about that last point.  Many of us spend a
great deal of time and effort here *explaining* how C is defined
and how best to use it.

To explain is not to defend.  What will it take for you to understand
that?

[...]

> It is also frustrating looking at C forums and people thinking they
> are too stupid to grasp something when it's language that could have
> been better.

(I'm going to assume I parsed that sentence correctly.)

Nobody has said that C couldn't have been better.  But it could
hardly have been more successful.  As Dennis Ritchie himself said,
"C is quirky, flawed, and an enormous success."

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#11789

On 12/05/2026 02:37, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> I don't have much of a problem with the things that C can do, but with
>> how it does it, its syntax, its ancient baggage, its quirks, its
>> folklore, its Unix-centric ecosystem, its pointless UBs, its
>> insistence in working with every oddball processor, its solving every
>> shortcoming with macros, its adherents who will defend every
>> misfeature to the death...
> 
> You're mostly wrong about that last point.  Many of us spend a
> great deal of time and effort here *explaining* how C is defined
> and how best to use it.

I don't see the connection with my point. I haven't said that people 
don't explain things.

But it does seem that every poor feature in C is an invaluable asset to 
somebody, that must never be fixed.

So the inconvenience of how 'switch' works is excused because 
/sometimes/ you need fallthrough, or the one time in a thousand you need 
Duff's device.

> To explain is not to defend.  What will it take for you to understand
> that?
> 
> [...]
> 
>> It is also frustrating looking at C forums and people thinking they
>> are too stupid to grasp something when it's language that could have
>> been better.
> 
> (I'm going to assume I parsed that sentence correctly.)
> 
> Nobody has said that C couldn't have been better.  But it could
> hardly have been more successful.  As Dennis Ritchie himself said,
> "C is quirky, flawed, and an enormous success."

Yeah, it's one of the great mysteries. Even half a century ago, there 
were big companies and lots of clever people, who could have cranked out 
a suitable systems language of equal capability to C in their sleep, but 
with fewer rough edges.

I wonder why they didn't? Maybe they would have been aimimg too high 
even then? (Instead we got Smalltalk and Ada.)

> 
> [...]
> 

[toc] | [prev] | [next] | [standalone]

#11790

On Tue, 12 May 2026 22:32:30 +0100
Bart <bc@freeuk.com> wrote:

> Even half a century ago, there were big companies and lots of clever
> people, who could have cranked out a suitable systems language of
> equal capability to C in their sleep, but with fewer rough edges.
> 
> I wonder why they didn't?

I am reminded of Seymour Cray's rebuttal to Tom Watson:

"I understand that in the laboratory developing this system there are
only 34 people, 'including the janitor.' Of these, 14 are engineers and
4 are programmers, and only one has a Ph. D., a relatively junior
programmer. To the outsider, the laboratory appeared to be cost
conscious, hard working and highly motivated.

Contrasting this modest effort with our own vast development
activities, I fail to understand why we have lost our industry
leadership position by letting someone else offer the world’s most
powerful computer."

"It seems like Mr. Watson has answered his own question."

[toc] | [prev] | [next] | [standalone]

#11792

On 2026-05-13 00:28, John Ames wrote:
> On Tue, 12 May 2026 22:32:30 +0100
> Bart <bc@freeuk.com> wrote:
> 
>> Even half a century ago, there were big companies and lots of clever
>> people, who could have cranked out a suitable systems language of
>> equal capability to C in their sleep, but with fewer rough edges.
>>
>> I wonder why they didn't?
> 
> I am reminded of Seymour Cray's rebuttal to Tom Watson:
> 
> "I understand that in the laboratory developing this system there are
> only 34 people, 'including the janitor.' Of these, 14 are engineers and
> 4 are programmers, and only one has a Ph. D., a relatively junior
> programmer. To the outsider, the laboratory appeared to be cost
> conscious, hard working and highly motivated.
> 
> Contrasting this modest effort with our own vast development
> activities, I fail to understand why we have lost our industry
> leadership position by letting someone else offer the world’s most
> powerful computer."
> 
> "It seems like Mr. Watson has answered his own question."

Hmm.. - I wonder what the amount of involved people is supposed to
tell us here? - There's sophisticated languages where international
committees with many members spent huge efforts, and there's also
extremely ambitious languages where less than a handful of experts
designed and developed it. - I mean, now concerning "C", does that
in any way makes the difference or explains anything concerning the
actual "C" design (with its strengths and with its shortcomings and
inherent deficiencies)?

My (very subjective) impression is that "leadership positions" were
primarily defined by other factors the past decades; spanning from
commercial market-power to thorough marketing activities.

Janis

[toc] | [prev] | [next] | [standalone]

#11791

Bart <bc@freeuk.com> writes:
>On 12/05/2026 02:37, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
 <snip> 
>> 
>> Nobody has said that C couldn't have been better.  But it could
>> hardly have been more successful.  As Dennis Ritchie himself said,
>> "C is quirky, flawed, and an enormous success."
>
>Yeah, it's one of the great mysteries. Even half a century ago, there 
>were big companies and lots of clever people, who could have cranked out 
>a suitable systems language of equal capability to C in their sleep, but 
>with fewer rough edges.

Those clever people _were_ cranking out suitable systems languages
by the bucketful.    PL/1, Algol derivatives, proprietary internal
languages (Burroughs SPRITE and BPL languages), HP-3000 SPL (Systems
Programming Language - I used SPL in the late 70s) and
on the academic side, modula, ADA, Pascal (yes, it could be
a systems programming language, c.f. VAX-11 Pascal).

They weren't aiming at your 70's target 8080 processors, although
there was PL/M and a few others for the 8080 at the time.

https://en.wikipedia.org/wiki/PL/M

[toc] | [prev] | [next] | [standalone]

#11793

On 2026-05-13 01:21, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 12/05/2026 02:37, Keith Thompson wrote:
>>> [...]
>>
>> Yeah, it's one of the great mysteries. Even half a century ago, there
>> were big companies and lots of clever people, who could have cranked out
>> a suitable systems language of equal capability to C in their sleep, but
>> with fewer rough edges.
> 
> Those clever people _were_ cranking out suitable systems languages
> by the bucketful.    PL/1, Algol derivatives, proprietary internal
> languages (Burroughs SPRITE and BPL languages), HP-3000 SPL (Systems
> Programming Language - I used SPL in the late 70s) and
> on the academic side, modula, ADA, Pascal (yes, it could be
> a systems programming language, c.f. VAX-11 Pascal).
> 
> [...]

I wonder about why you put Ada just in the "academic box".

Janis

[toc] | [prev] | [next] | [standalone]

#11794

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 2026-05-13 01:21, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 12/05/2026 02:37, Keith Thompson wrote:
>>>> [...]
>>>
>>> Yeah, it's one of the great mysteries. Even half a century ago, there
>>> were big companies and lots of clever people, who could have cranked out
>>> a suitable systems language of equal capability to C in their sleep, but
>>> with fewer rough edges.
>> 
>> Those clever people _were_ cranking out suitable systems languages
>> by the bucketful.    PL/1, Algol derivatives, proprietary internal
>> languages (Burroughs SPRITE and BPL languages), HP-3000 SPL (Systems
>> Programming Language - I used SPL in the late 70s) and
>> on the academic side, modula, ADA, Pascal (yes, it could be
>> a systems programming language, c.f. VAX-11 Pascal).
>> 
>> [...]
>
>I wonder about why you put Ada just in the "academic box".

Because the first ADA compiler I used came from NYU. :-)

[toc] | [prev] | [next] | [standalone]

#11795

scott@slp53.sl.home (Scott Lurndal) writes:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
>>I wonder about why you put Ada just in the "academic box".
>
> Because the first ADA compiler I used came from NYU. :-)

It's Ada, not ADA.  It's a person's name, not an acronym.

And along with C, it's one of the few languages whose name is a
hexadecimal palindrome.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#11796

In article <10u2jgv$2t96p$5@kst.eternal-september.org>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>[...]
>>>I wonder about why you put Ada just in the "academic box".
>>
>> Because the first ADA compiler I used came from NYU. :-)
>
>It's Ada, not ADA.  It's a person's name, not an acronym.

Perhaps Scott was alluding to its design reminding one of the
era in which only upper case characters were available on one's
teletype.  :-D

	- Dan C.

(I'm kidding again.  I actually don't think Ada is a terrible
language.)

[toc] | [prev] | [next] | [standalone]

#11836 — SPL/3000 (was Re: Alternatives to C)

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)

I’m interested to hear how SPL compared to C and Pascal from your
perspective.  I’ve never talked to anyone who had the chance to use it.
Glancing at
<http://bitsavers.informatik.uni-stuttgart.de/pdf/hp/3000/spl/30000-90025_System_Programming_Language_Textbook_197709.pdf#page=124>
it looks pretty similar to them — a bit longer-winded and SHOUTIER than
C, a bit more practical than Pascal, but showing a very strong family
resemblance to both.

One difference that leaps out at me is that, as with VAR parameters in
Pascal or references in C++, dereferencing pointers apparently happens
implicitly — it’s only when you want to reseat the pointer that you need
to use the @ operator.  But possibly I’m guessing wrong, since I haven’t
actually read the textbook.

Kragen

[toc] | [prev] | [next] | [standalone]

#11837 — Re: SPL/3000 (was Re: Alternatives to C)

On Thu, 27 Aug 2026 21:30:41 -0300, Kragen Javier Sitaker wrote:

> I’m interested to hear how SPL compared to C and Pascal from your
> perspective. I’ve never talked to anyone who had the chance to use
> it. Glancing at
> <http://bitsavers.informatik.uni-stuttgart.de/pdf/hp/3000/spl/30000-90025_System_Programming_Language_Textbook_197709.pdf#page=124>
> it looks pretty similar to them — a bit longer-winded and SHOUTIER
> than C, a bit more practical than Pascal, but showing a very strong
> family resemblance to both.

It’s an ALGOL-60 derivative, complete with call-by-name for
function/procedure arguments and a paucity of control constructs, it
appears.

[toc] | [prev] | [next] | [standalone]

#11838 — Re: SPL/3000 (was Re: Alternatives to C)

On Thu, 27 Aug 2026 21:30:41 -0300, Kragen Javier Sitaker wrote:

> I’m interested to hear how SPL compared to C and Pascal from your
> perspective. I’ve never talked to anyone who had the chance to use
> it. Glancing at
> <http://bitsavers.informatik.uni-stuttgart.de/pdf/hp/3000/spl/30000-90025_System_Programming_Language_Textbook_197709.pdf#page=124>
> it looks pretty similar to them — a bit longer-winded and SHOUTIER
> than C, a bit more practical than Pascal, but showing a very strong
> family resemblance to both.

It’s an ALGOL-60 derivative, complete with call-by-name for
function/procedure arguments and a paucity of control constructs, it
appears.

[toc] | [prev] | [next] | [standalone]

#11840 — Re: SPL/3000 (was Re: Alternatives to C)

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)
>
>I’m interested to hear how SPL compared to C and Pascal from your
>perspective.  I’ve never talked to anyone who had the chance to use it.

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.

[toc] | [prev] | [next] | [standalone]

#11842 — Re: SPL/3000 (was Re: Alternatives to C)

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] | [prev] | [next] | [standalone]

#11843 — Re: SPL/3000 (was Re: Alternatives to C)

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]

#11851 — Re: SPL/3000 (was Re: Alternatives to C)

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]

#11856 — Re: SPL/3000 (was Re: Alternatives to C)

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]

#11857 — Re: SPL/3000 (was Re: Alternatives to C)

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] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.misc

csiph-web