[NCLUG] A brief note about C and potential successors.

[Bob Proulx]

Brian Sturgill wrote:
> My first major programming job was writing admissions software on a PDP
> 11/10 running V6 Mini Unix.

A classic system!  I really one one of these new reproductions of the
classic front panel.  The new panel is a beautiful and loving
recreation at a reduced size scale.

  https://obsolescence.wixsite.com/obsolescence/pidp-11

Couple that with Pi running the simh simulator and you can have a
loving recreation of the venerable old PDP-11 of your very own!

> The 11/10 did not have separate I and D spaces, so user programs had to fit
> in 32K bytes of memory.

I remember one of the problems I would run into with the HP Focus cpu
was that it did have separate I and D space.  Which made it impossible
to use a struct union holding pointers to both I and D.  Which made it
impossible to compile a few programs that made use of that feature.

Of course I simply ported the software and modified it to split that
union into two parts.  But needing to do it is why I remember that it
was a problem.  The C compiler would compile it to assembly but then
the assembler would throw an assembler error!  That was definitely
very odd to see.

> This computer was sized similarly to the original machines C was made for.
> The compiler ran fine there, but you had to be careful to use short
> variable names or you ran out of memory.
> I actually have the system source code around somewhere, I'll look into
> bringing it for "show and tell".

That would be fun! :-)

> People at that time would say you're crazy to to be using C in such a small
> amount of memory.
> Yet the whole multi user operating system (95% written in C) fit in 20K.

C itself does not produce that inefficient code as compared to just
randomly writing assembly language for some random task.  And probably
most of the time the C program won't need as much debugging as the
assembler one.  Probably.  I think it is safe to say.

The place where C can really get bloated though is using something
like printf().  Since the format string *might* be using a floating
point format then using printf() anywhere in the program even once
pulls in the entire floating point library!  Which is quite large.
Also there are other instances where library code can have the effect
of pulling in a lot of extra code that is not desired making
executables quite large.  But the C program part of it was just the
small part of it.

> Now consider Arduinos. I normally use ESP8266-based chips.
> These have 32K instruction, 32K instruction cache,  80K user-data, 16K
> system data
> Or about 4 times the memory of the PDP 11/10.
> It also has the ability to execute instructions and pull data from a 4Mb
> flash RAM.
> Making it in practice more than an order of magnitude more memory.
> The processor is many times faster than the PDP 11/10.
> The PDP 11/10 was multi-user... we regularly ran 2 users at a time there.
> Arduinos are single program chips and only load the parts of the limited OS
> it needs.

That would make it a great system for C programs!

> My point here is if it was reasonable to run C on the 11/10, why is Go or
> Rust or Swift unreasonable on these "tiny" chips now?

I don't think that argument really flows.  But I know it was at the
end of your message and you were probably in a hurry to send it off.
However I see where you are going with it.

I did not realize that Arduinos were that large these days already.

If the current Arduinos have that much memory and storage then that
does seem quite large enough to handle a garbage collected language
like Go-lang and Python just fine.  If it is large enough to do what
you want it to do then by all means use those languages.  Programmer
productivity is usually higher in garbage collected languages.  So you
will probably get done sooner and have fewer bugs to debug along the
way.

Bob