C, please die, and take Go with you - Re: Fwd: is there any word processing software for the pdp11?

[Dave G4UGM]

Having maintained X.25 networking software written in Fortran-77 when I
worked at Salford University, and written large amounts of Software on
Honeywell L66 and DPS8 kit using "B", give me "C" any day. So a couple of
answers:-

1. WHY Fortran-77

Well at the time many of the machines we were targeting did not have "C"
compilers that were widely available to all owners of the machines. 
I think the major ones were ICL2900, Prime and IBM 370 series. All these had
Fortran-77 installed and usable as we were providing code to UK
Universities.
Apart from the perhaps the Prime none had "C" compilers generally
installed...

2.HOW?

A major problem was there is no dynamic memory in Fortran-77. So we defined
a large array of Character Variables (we called each element a "block") and
then a matrix of integers. Each Character Variable in the array had some
matching integers that could be used to define how the data in the character
variable was to be used, so essentially a "Block Type". As Fortran-77
supports include files we had includes that defined offsets into the
Character Variables and so defined the block structure.......

Of course Fortran or its standard run-time library has no concept of
networking so there was a host of machine dependant code hidden  in a
subroutine library. 

Definitely a total mis-use of the poor innocent Fortran-77 compiler, which I
must say we broke on a frequent basis....

Dave
G4UGM

> -----Original Message-----
> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Guy
> Sotomayor
> Sent: 04 December 2014 19:13
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: C, please die, and take Go with you - Re: Fwd: is there any
word
> processing software for the pdp11?
> 
> 
> > On Dec 4, 2014, at 10:59 AM, Chuck Guzis <cclist at sydex.com> wrote:
> >
> > On 12/04/2014 09:52 AM, Fred Cisin wrote:
> >
> >> Is C more dangerous than Assembly?
> >
> > No, it isn't--it does, however, lack a good macro facility.  Sadly, good
macro
> facilities for assemblers have been going out of style.  Witness the
> assemblers for modern MCUs.  It's pretty much assumed that these will be
> programmed in C--that's what the tool suite is written in and it's
expected
> that this is what people will use.  An assembler is done because it's
> customary.
> >
> > Viewed as a low-level implementation language a step above assembly,
> run-time error checking is ridiculous.  What do you do in an OS kernel
when
> an exception is thrown because of a coding error?  You die--maybe with
> some diagnostic information.  Very often, there's no way forward.
> >
> > What a OS kernel programmer worries about is unexpected behavior of
> physical devices.  What do you do if a device dies in the middle of an
> operation? What if a device simply misbehaves?   Easy--you detect it and
die.
> >
> > BSODs, DEADBEEF errors, you name it.
> >
> > You try to be as careful as you can be, coding correctly.  If you can
get a
> buffer overrun, you should be checking for it.  If you try to page out the
> resident pager code, you did something wrong and no runtime error
> checking is going to fix that.
> >
> > C is a chainsaw, as others have said.  So is assembly.  Trying to change
it into
> a screwdriver is a hopeless task.  Just the idea of unrestricted pointers
makes
> good run-time diagnosis hopeless and is the bane of automatic compile-time
> optimization.
> >
> > I am in favor of very good compile-time diagnostics, no matter the
> language, however.   Getting 150 error messages because you forgot to
close
> a brace somewhere is just stupid.
> 
> To add to this.  In a couple of places I was "forced" to use static
analysis tools
> to "check" my code.
> This was usually required before a check-in.  The problem with the
analysis
> tools is that:
> (a) they didn't understand the kernel environment that I was working in
(see
> Chuck's earlier comment)
> (b) they didn't understand (or weren't sophisticated enough) to understand
> that certain conditions were
>      *can't* happen conditions but the tool would throw errors which in
order
> to remove (the errors) code
>      needed to be added that induced code-bloat and performance
reductions.
> 
> In the end, enough of us "kernel hacks" got management to relent and not
> require the tool to be run on kernel code.  We just ran with all error
checks
> enabled in the standard compiler.
> 
> TTFN - Guy