history of Programming language and CPU in relation to each other

[Rajib Kumar Bandopadhyay]

Dear friends,
I am a subscriber of comp.unix.shell. I was directed to your usergroup by
Dan Espen. I posted the following email to that group:
=======================================================
I have been toying with an idea for a long time. How can I delve into the
history of Programming language and CPU - how to watch with my own eyes
and understand their demerits?

I know there are many links on the web, like
http://en.wikipedia.org/wiki/Timeline_of_programming_languages ,
http://en.wikipedia.org/wiki/Analytical_engine and others, but how to
watch things happening in an actual machine, learn how to program it and
then understanding the earlier paradigm by programming it myself.
Just like I have learnt the basics of physics and mathematics by first
principles, I wish to follow the same route by delving into history and
operations of these computational machines.
I am being naive, but will someone help me on this? Since you guys are
deeply into coding you would be the best ones to guide me on this?
=======================================================
Hope you help me regarding this. I found way too much information in your
group, beyond my level of comprehension and also randomly scattered
across the group-discussions.

I received the following information from Dan, Mirko, Janis and others
from comp.unix.shell:

...
Computers and programming started to really take off with the
introduction of the IBM 1401. There is at least one simulator
available.
You can find the manuals at bitsavers.
...
Anyway, there are a large number of simulators for historical
machines, as well as implementations for ancient programming
languages (I'm sure I've seen for example PL1 and APL
implementations for modern Linux systems).
Have a look at the SIMH project (I sometimes enjoy playing around
with the PDP11 and UNIX v7 environment).
http://simh.trailing-edge.com/
...
Well, the IBM 1401 was a fascinating machine, programmed mostly in it's
machine language (Autocoder is it's assembly language). Knowing how it
made it's registers available for stealth use, and how it used a bit in
each character position to delimit fields and instructions is
interesting.
...
Any 1401 programmer would be well versed in the machine language,
but the machine was normally programmed in Autocoder.
Machine language was for writing patches which were punched up and
inserted in the object deck.
Recompiles took too long for small changes
...
When you have discovered what some of the early hardware was, you can
then search for 'simulators', and/or 'emulators' of that hardware.
THEN you need to learn the assembler language for that machine, so that
you can write some trivial programs in that language, and watch them run
in the simulator/emulator.
...


I also sent an email to aek at bitsavers dot org, link: http://
bitsavers.informatik.uni-stuttgart.de/ requesting an overview of what the
site does, but received no information till date.
I also have been to the site http://simh.trailing-edge.com/ but I can
understand from where to begin.
Please tell me from where to start (the route of least resistance),
because I learn things hands on,getting a feel of things while I go along.
Regards
Rajib Bandopadhyay

[Shmuel Metz]

In <k52uap$h64$1...@dont-email.me>, on 10/10/2012

at 04:42 AM, Rajib Kumar Bandopadhyay <bkpsu...@gmail.com> said:

>I have been toying with an idea for a long time. How can I delve into
>the history of Programming language and CPU - how to watch with my
>own eyes and understand their demerits?

For those that are available on bitsavers, read the manuals. For
others, it's a bit dicier, but check, e.g., ACM, IEEE, for papers.

>Well, the IBM 1401 was a fascinating machine, programmed mostly in
>it's machine language (Autocoder is it's assembly language).

1401 Autocoder was *an* assembler for the 1401, but those without
disks or enough tape drives were stuck with SPS. I don't know of
anybody who wrote a serious program in machine language, although I
have seen people do machine-language patches to avoid a reassembly - a
dangerous practice IMHO.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Peter Flass]

On 10/10/2012 2:03 AM, Shmuel (Seymour J.) Metz wrote:
> In <k52uap$h64$1...@dont-email.me>, on 10/10/2012
> at 04:42 AM, Rajib Kumar Bandopadhyay <bkpsu...@gmail.com> said:
>
>> I have been toying with an idea for a long time. How can I delve into
>> the history of Programming language and CPU - how to watch with my
>> own eyes and understand their demerits?
>
> For those that are available on bitsavers, read the manuals. For
> others, it's a bit dicier, but check, e.g., ACM, IEEE, for papers.

Better have lots of money. These organizations seem to be going out of
their way to discourage research. If nothing else they should have a
statute of limitations on charges, for example charge for anything newer
than 10 years; anything older is free.

--
Pete

[Louis Krupp]

On Wed, 10 Oct 2012 04:42:04 +0000 (UTC), Rajib Kumar Bandopadhyay
<bkpsu...@gmail.com> wrote:

>Dear friends,
>I am a subscriber of comp.unix.shell. I was directed to your usergroup by
>Dan Espen. I posted the following email to that group:
>=======================================================
>I have been toying with an idea for a long time. How can I delve into the
>history of Programming language and CPU - how to watch with my own eyes
>and understand their demerits?

First, look up "demerit" in the dictionary. My guess is that "merit"
is the word you really want.

Second, a few months ago, someone on alt.folklore.computers mentioned
a book about computer hardware and architecture (I think it was a
relatively recent publication) that might be useful. I wish I could
remember more; perhaps someone else can help.

As far as computer history goes, this might be interesting:

http://www.amazon.com/First-Computers--History-Architectures-History-Computing/dp/0262681374/ref=sr_1_3?s=books&ie=UTF8&qid=1349875351&sr=1-3&keywords=Computer+history

<snip>

Louis

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <k52uap$h64$1...@dont-email.me>, on 10/10/2012
> at 04:42 AM, Rajib Kumar Bandopadhyay <bkpsu...@gmail.com> said:
>
>>I have been toying with an idea for a long time. How can I delve into
>>the history of Programming language and CPU - how to watch with my
>>own eyes and understand their demerits?
>
> For those that are available on bitsavers, read the manuals. For
> others, it's a bit dicier, but check, e.g., ACM, IEEE, for papers.
>
>>Well, the IBM 1401 was a fascinating machine, programmed mostly in
>>it's machine language (Autocoder is it's assembly language).
>
> 1401 Autocoder was *an* assembler for the 1401, but those without
> disks or enough tape drives were stuck with SPS. I don't know of
> anybody who wrote a serious program in machine language, although I
> have seen people do machine-language patches to avoid a reassembly - a
> dangerous practice IMHO.

Yeah, poorly worded sentence on my part.
I was trying to refer Autocoder/SPS as languages that used the machine
instructions directly.

Of course, any 1401 programmer would frequently also use machine
language to construct patches which was a common practice.

--
Dan Espen

[Dan Espen]

Rajib Kumar Bandopadhyay <bkpsu...@gmail.com> writes:

> I also sent an email to aek at bitsavers dot org, link: http://
> bitsavers.informatik.uni-stuttgart.de/ requesting an overview of what the
> site does, but received no information till date.

Not sure why you sent email.

They keep copies of old manuals.

Doing a searche for old computers for example "1401 autocoder
bitsavers" will find the manual used to program the machine.

--
Dan Espen

[hanc...@bbs.cpcn.com]

On Oct 10, 12:42 am, Rajib Kumar Bandopadhyay <bkpsusmi...@gmail.com>
wrote:

> I have been toying with an idea for a long time. How can I delve into the
> history of Programming language and CPU - how to watch with my own eyes
> and understand their demerits?

In very simple form:

The history of programming languages and the history of CPU are two
separate issues. They developed separately.

The history of CPU would be a history of technology-starting with
relays, then vacuum tubes, transistors, and then integrated circuits.

The history of programming languages would be a machine language for
each machine, then an assembler language for the machine language.

"High level languages" came next, such as COBOL and FORTRAN. They had
a more English like appearance and were somewhat independent of the
specific machine they would run on. They were "compiled" or
translated into machine language by a special program.

Two books:

"Computer" by Aspray-Kelly (general summary history)
"IBM's Early Computers" by Bashe et al. (more detailed)

[Shmuel Metz]

In <hata785nsknajpuue...@4ax.com>, on 10/10/2012

at 07:31 AM, Louis Krupp <lkr...@nospam.pssw.com.invalid> said:

>First, look up "demerit" in the dictionary. My guess is that "merit"
>is the word you really want.

I've been working with computers for half a century, and merit is
rather thin on the ground. Even the languages, machines and operating
systems that I liked most had serious flaws. I suspect that demerit is
the word he meant.

[hanc...@bbs.cpcn.com]

On Oct 10, 7:45 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> Better have lots of money.  These organizations seem to be going out of
> their way to discourage research.  If nothing else they should have a
> statute of limitations on charges, for example charge for anything newer
> than 10 years; anything older is free.

I can understand charging a fee for access to defray storage costs,
but their fees are rather high, IMHO. IBM transferred their journals
to them and there is a steep fee, too.

As mentioned, Bell Labs Technical Journal are available free on-line.

FWIW, very old articles in the New York Times may be pulled up for
free. If one is curious about IBM 100 years ago (as Computing-
Tabulating-Recording), you can look it up. But it was a very small
company then and little was said about it. Heck, even in the 1950s
the announcement of the disk drive warranted only a few sentences in
the NYT. However, the April 1964 S/360 announcement was a big deal
(unfortunately, there is a charge for those archives, unless you go
through a library.) IBM had chartered a full train to take
journalists up to see a big demonstration.

[Al Kossow]

On 10/9/12 9:42 PM, Rajib Kumar Bandopadhyay wrote:
> Dear friends,
> I am a subscriber of comp.unix.shell. I was directed to your usergroup by
> Dan Espen. I posted the following email to that group:
> =======================================================
> I have been toying with an idea for a long time. How can I delve into the
> history of Programming language and CPU - how to watch with my own eyes
> and understand their demerits?
>

a few things to look at re. programming languages:

http://www.webber-labs.com/mpl/lectures/pdf-slides/24.pdf
http://bitsavers.trailing-edge.com/pdf/stanford/cs_techReports/STAN-CS-76-562_EarlyDevelPgmgLang_Aug76.pdf
http://www.cs.umbc.edu/331/resources/papers/sammet1972.pdf
http://www.amazon.com/Programming-Languages-Fundamentals-Automatic-Computation/dp/0137299885

[Nick Spalding]

hanc...@bbs.cpcn.com wrote, in
<358e6373-0380-4fef...@e18g2000yqo.googlegroups.com>
on Wed, 10 Oct 2012 18:31:12 -0700 (PDT):

In the Education Center (or whatever it was called) at Poughkeepsie
where I was learning the 7010 at the time. We all got the day off, it
wouldn't have been proper for us to see them dishing out the demon
alcohol to all the journalists.
--
Nick Spalding

[bkpsu...@gmail.com]

On Wednesday, 10 October 2012 19:16:39 UTC+5:30, Dan Espen wrote:
...

> Not sure why you sent email.
> They keep copies of old manuals.

That was what I wanted to know. For a dimwit like me it was a challenge to find what the site is doing, and how. I found a lot of pdf files, and since I have only begun, index by date did not help much.
Thanks.

[bkpsu...@gmail.com]

On Thursday, 11 October 2012 03:19:33 UTC+5:30, Seymour J. Shmuel Metz wrote:
> I suspect that demerit is
> the word he meant.

Precisely, newer systems are developed to overcome the difficulties with the present systems.
Please, let us stop this thread and continue with our discussion on the history part.

[bkpsu...@gmail.com]

On Thursday, 11 October 2012 06:56:13 UTC+5:30, (unknown) wrote:
> In very simple form:
...
Thank you for the lovely summary. I am aware of the overview from wikipedia, but I need hands-on feel. Simulators/emulators should be good for me.

[bkpsu...@gmail.com]

On Wednesday, 10 October 2012 17:15:35 UTC+5:30, Peter Flass wrote:
...

> Better have lots of money. These organizations seem to be going out of
> their way to discourage research.

Imagine what would happen in Banana republics if such is the case for the US which is established on the principles of naturalism.
Oswald Spengler comes to mind...

[Peter Flass]

On 10/10/2012 9:26 PM, hanc...@bbs.cpcn.com wrote:
> On Oct 10, 12:42 am, Rajib Kumar Bandopadhyay <bkpsusmi...@gmail.com>
> wrote:
>
>> I have been toying with an idea for a long time. How can I delve into the
>> history of Programming language and CPU - how to watch with my own eyes
>> and understand their demerits?
>
> In very simple form:
>
> The history of programming languages and the history of CPU are two
> separate issues. They developed separately.

They really did develop in tandem. Why was Autocoder the most popular
language on 14xx machines? COBOL was available at the time, why not use
it? One big reason is the time it took to compile a COBOL program, the
system wasn't big or fast enough. Look at IBM's OS/360 compilers - why
did they have multiple versions like FORTRAN D, FORTRAN E, FORTRAN H,
etc.? Because memory was a major restriction and they had to trade-off
features and capability in order to get the compiler to fit. This is
probably the biggest factor why C and not PL/I became popular on micros,
the machines couldn't support anywhere a near-complete PL/I compiler
(Digital Research PL/I is an accomplishment, but not full PL/I.)

--
Pete

[Ahem A Rivet's Shot]

On Thu, 11 Oct 2012 07:43:00 -0400
Peter Flass <Peter...@Yahoo.com> wrote:

> They really did develop in tandem. Why was Autocoder the most popular
> language on 14xx machines? COBOL was available at the time, why not use
> it? One big reason is the time it took to compile a COBOL program, the
> system wasn't big or fast enough. Look at IBM's OS/360 compilers - why
> did they have multiple versions like FORTRAN D, FORTRAN E, FORTRAN H,
> etc.? Because memory was a major restriction and they had to trade-off
> features and capability in order to get the compiler to fit. This is
> probably the biggest factor why C and not PL/I became popular on micros,

The first CP/M C compiler I used was a cut down implementation.
They left out bitfields among other things (unions too I think). It's a pity
that the code I'd written while waiting for the compiler to arrive was
littered with bitfields.

So yes compact, easy to compile languages were important in the
early days of micros. I did meet an Algol68 compiler that compiled for CP/M
- but it ran on a 370 not a Z80. Most of my CP/M programming was in a
mixture of C and Assembler - I think that was pretty typical, although I
did once encounter a COBOL compiler for CP/M, I expect it made good use of
the overlay facilities.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[Walter Bushell]

In article <50750fcb$1$fuzhry+tra$mr2...@news.patriot.net>,

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid>

wrote:

> In <k52uap$h64$1...@dont-email.me>, on 10/10/2012
> at 04:42 AM, Rajib Kumar Bandopadhyay <bkpsu...@gmail.com> said:
>
> >I have been toying with an idea for a long time. How can I delve into
> >the history of Programming language and CPU - how to watch with my
> >own eyes and understand their demerits?
>
> For those that are available on bitsavers, read the manuals. For
> others, it's a bit dicier, but check, e.g., ACM, IEEE, for papers.
>
> >Well, the IBM 1401 was a fascinating machine, programmed mostly in
> >it's machine language (Autocoder is it's assembly language).
>
> 1401 Autocoder was *an* assembler for the 1401, but those without
> disks or enough tape drives were stuck with SPS. I don't know of
> anybody who wrote a serious program in machine language, although I
> have seen people do machine-language patches to avoid a reassembly - a
> dangerous practice IMHO.

It was standard practice at NASA where I worked, for transmitter
command and control. To do a link and load we would all gather at some
convenient time like 3 AM and load paper tapes into the confuser.
After that cassette tapes would be sent to the transmitters.

For patches between these events we would produce patch tapes that
would be loaded after the masters. I was a big deal to do a recompile
and load, because more checking had to be done before release.

--
This space unintentionally left blank.

[Walter Bushell]

In article
<02a8129c-3910-4dc0...@e18g2000yqo.googlegroups.com>,

hanc...@bbs.cpcn.com wrote:

> In very simple form:
>
> The history of programming languages and the history of CPU are two
> separate issues. They developed separately.

Actually interdependently.

With at least two connections. High level languages depended on
cheapness of processors that could support them. You would need a very
high end 1401 to support COBOL.

C and has a lot of assumed computer architecture built in. Memory is
assumed to be byte addressable and contiguous and if your byte size is
anything other than 8 bits, you will have trouble with the standard
library etcetera.

Consider writing a C compiler for the DEC 10, which was very byte
friendly for a word oriented machine.

[jmfbahciv]

Shmuel (Seymour J.) Metz wrote:

> In <hata785nsknajpuue...@4ax.com>, on 10/10/2012
> at 07:31 AM, Louis Krupp <lkr...@nospam.pssw.com.invalid> said:
>
>>First, look up "demerit" in the dictionary. My guess is that "merit"
>>is the word you really want.
>
> I've been working with computers for half a century, and merit is
> rather thin on the ground. Even the languages, machines and operating
> systems that I liked most had serious flaws. I suspect that demerit is
> the word he meant.
>

We used the term "non-goal" when doing the development. If a trade-off
had to be done, the aspect favoring the non-goal list would be in
less favor than the aspect which favored the goal list.

and everything was a tradeoff because there is no such thing as perfect
code or hardware.

/BAH

[jmfbahciv]

High level languages evolved so that the same code didn't ahve to be
written over and over and over and over again. That's how libraries
coalesced. One should not have to think about how the computer
does(not) do arithmetic while writing calculations. The arithmetic
code can be written by "lesser" programmers while the numerical
analysis code was worked on by the physiciists. the same
was true for I/O and/or memory management. Even developing hardware
was based on black box thinking.

/BAH

[jmfbahciv]

Honey, you can't stop a rock which has started rolling down hill. In this
newsgroups, topics ramble in seemingly unrelated areas. However, if you
read closely, it all has something to do with how we did our work.

/BAH

[John Levine]

>C and has a lot of assumed computer architecture built in. Memory is
>assumed to be byte addressable and contiguous and if your byte size is
>anything other than 8 bits, you will have trouble with the standard
>library etcetera.

Early versions of C worked on the GE 635, which was word addressed
but had some rather fancy character addressing features.

Since then, the architectures that don't have 8-bit bytes have mostly
died*, so modern C does indeed strongly assume 8 bit byte addressed
memory. In principle C should handle segmented memory, in practice,
good luck.**

R's,
John


* - bet I get a lot of hassle from the Unisys crowd

** - I mean real segments, not the 8086
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

[Charles Richmond]

"Ahem A Rivet's Shot" <ste...@eircom.net> wrote in message
news:20121011133209.cb79...@eircom.net...

> On Thu, 11 Oct 2012 07:43:00 -0400
> Peter Flass <Peter...@Yahoo.com> wrote:
>
>> They really did develop in tandem. Why was Autocoder the most popular
>> language on 14xx machines? COBOL was available at the time, why not use
>> it? One big reason is the time it took to compile a COBOL program, the
>> system wasn't big or fast enough. Look at IBM's OS/360 compilers - why
>> did they have multiple versions like FORTRAN D, FORTRAN E, FORTRAN H,
>> etc.? Because memory was a major restriction and they had to trade-off
>> features and capability in order to get the compiler to fit. This is
>> probably the biggest factor why C and not PL/I became popular on micros,
>
> The first CP/M C compiler I used was a cut down implementation.
> They left out bitfields among other things (unions too I think). It's a
> pity
> that the code I'd written while waiting for the compiler to arrive was
> littered with bitfields.
>

I have programmed in C for circa 20 years... and I have yet to even use a
bitfield in a structure. I would wager that the bitfield is seldom used by
most C programmers. I did *once* have the occasion to use the
setjmp/longjmp facility.

> So yes compact, easy to compile languages were important in the
> early days of micros. I did meet an Algol68 compiler that compiled for
> CP/M
> - but it ran on a 370 not a Z80. Most of my CP/M programming was in a
> mixture of C and Assembler - I think that was pretty typical, although I
> did once encounter a COBOL compiler for CP/M, I expect it made good use of
> the overlay facilities.
>

Early compiler books like _Compiler Construction for Digital Computers_, by
David Gries... recommended *20* pass compilers. This was to overcome the
lack of main memory... doing the compilation in small slices.

--

numerist at aquaporin4 dot com

[Charles Richmond]

"Walter Bushell" <pr...@panix.com> wrote in message
news:proto-E473C6....@news.panix.com...

There *is* a C compiler for the PDP-10/DEC-20. It used 9-bit bytes.

[Charles Richmond]

"John Levine" <jo...@iecc.com> wrote in message
news:k56if8$1c80$1...@leila.iecc.com...

> >C and has a lot of assumed computer architecture built in. Memory is
>>assumed to be byte addressable and contiguous and if your byte size is
>>anything other than 8 bits, you will have trouble with the standard
>>library etcetera.
>
> Early versions of C worked on the GE 635, which was word addressed
> but had some rather fancy character addressing features.
>
> Since then, the architectures that don't have 8-bit bytes have mostly
> died*, so modern C does indeed strongly assume 8 bit byte addressed
> memory. In principle C should handle segmented memory, in practice,
> good luck.**
>

At a PPoE, I have programmed in C on a Harris 800. It is a 24-bit word
machine and is word addressible. It has a facility for addressing 8-bit
bytes within the word, though. This was in the mid 80's, so *not* long ago
like the GE 635. ISTM that Harris bought the computer company from
Datacraft, along with the architecture. The Harris 800 was built with
bit-slice microprocessors. It had a multiply *board* in it. :-) And also
implemented a cache.

I have to say that the compiler group at Harris was a great bunch of
programmers, and the compilers did an *excellent* job of optimizing the
resulting code. Most of the tricks used by the old-time FORTRAN programmers
(some did use the machine in the same lab) were unnecessary. For example,
common subexpression elimination. The programmers might write:

X = COS(ANGLE)
Y = SIN(ANGLE)
Z = X**2*Y**2 + X*Y - 47.0*X*Y**3;

... to avoid multiple calls to the sine and cosine functions. But the
Harris compiler did all this "under the covers". So one might as well
write:

Z = COS(ANGLE)**2*SIN(ANGLE) + COS(ANGLE)*SIN(ANGLE) -
47.0*COS(ANGLE)*SIN(ANGLE)

The resulting generated code would be pretty much the same.

[Dan Espen]

"Charles Richmond" <nume...@aquaporin4.com> writes:

> "Ahem A Rivet's Shot" <ste...@eircom.net> wrote in message
> news:20121011133209.cb79...@eircom.net...
>> On Thu, 11 Oct 2012 07:43:00 -0400
>> Peter Flass <Peter...@Yahoo.com> wrote:
>>
>>> They really did develop in tandem. Why was Autocoder the most popular
>>> language on 14xx machines? COBOL was available at the time, why not use
>>> it? One big reason is the time it took to compile a COBOL program, the
>>> system wasn't big or fast enough. Look at IBM's OS/360 compilers - why
>>> did they have multiple versions like FORTRAN D, FORTRAN E, FORTRAN H,
>>> etc.? Because memory was a major restriction and they had to trade-off
>>> features and capability in order to get the compiler to fit. This is
>>> probably the biggest factor why C and not PL/I became popular on micros,
>>
>> The first CP/M C compiler I used was a cut down implementation.
>> They left out bitfields among other things (unions too I
>> think). It's a pity
>> that the code I'd written while waiting for the compiler to arrive was
>> littered with bitfields.
>>
>
> I have programmed in C for circa 20 years... and I have yet to even
> use a bitfield in a structure. I would wager that the bitfield is
> seldom used by most C programmers. I did *once* have the occasion to
> use the setjmp/longjmp facility.

A bit makes an ideal yes or no type switch, but if I'm writing everyday
application code, I'll create a "YORN" instead. (A character field
containing a Y OR N.)

When you're not writing everyday code, things change.

The Fvwm window manager (for X11), has a huge number of options that
can be set for different types of windows, (in Fvwm terms, Style
options). Most of these are represented by bits in a rather large
bit structure.

When this was designed, we were concerned that the compiler might be
inefficient testing a single bit in a large array of bits compared to
testing a character so we examined the generated code for setting and
testing bits on a number of platforms, with different compilers.
Turned out C does a pretty good job working with large bit structures.

--
Dan Espen

[Ahem A Rivet's Shot]

On Thu, 11 Oct 2012 09:19:32 -0500
"Charles Richmond" <nume...@aquaporin4.com> wrote:

> "Ahem A Rivet's Shot" <ste...@eircom.net> wrote in message
> news:20121011133209.cb79...@eircom.net...
> > On Thu, 11 Oct 2012 07:43:00 -0400
> > Peter Flass <Peter...@Yahoo.com> wrote:

> > The first CP/M C compiler I used was a cut down implementation.
> > They left out bitfields among other things (unions too I think). It's a
> > pity
> > that the code I'd written while waiting for the compiler to arrive was
> > littered with bitfields.
> >
>
> I have programmed in C for circa 20 years... and I have yet to even use a
> bitfield in a structure. I would wager that the bitfield is seldom used
> by most C programmers. I did *once* have the occasion to use the
> setjmp/longjmp facility.

Yes, well I was writing a table driven assembler/disassembler. It
seemed like a good idea to make the definition tables good and tight. I've
also used them for packing status fields into words when I want to be
stingy with memory.

[Quadibloc]

On Oct 9, 10:42 pm, Rajib Kumar Bandopadhyay <bkpsusmi...@gmail.com>
wrote:

> How can I delve into the
> history of Programming language and CPU - how to watch with my own eyes
> and understand their demerits?

There is a lot of information about specific CPUs and specific
programming languages on Bitsavers.

As to an overview of programming language history -

well, briefly, it went like this:

There were some early systems of higher-level languages such as MATH-
MATIC and FLOW-MATIC at Univac, and the interesting Klerer-May system
which allowed one to program in two-dimensional mathematical style,
building up summation and product symbols from parts.

But higher-level language programming took off when FORTRAN was
written for the IBM 704, because that compiler had optimizing features
that meant that programs were competitive with those written in
assembler language. (At that time, computer time cost hundreds of
dollars per hour, and computers were much less powerful than they are
today, so computer time cost much more than people time in writing
programs.)

The computer language ALGOL (ALGOL 58 and its more popular successor
ALGOL 60) introduced structured programming, which was adopted by
nearly all subsequent languages. It was particularly carried forwards
in Pascal.

The language C is of importance: it began as a general-purpose
programming language with extensive bit manipulation capabilities so
that it could be used to replace assembler language for writing
systems programs, but it gave rise to C++, which also incorporated
object-oriented programming, which many languages today use.

As to the relationship between the evolution of computer instruction
sets and computer languages -

well, there isn't much of a relation.

On my web site, at

http://www.quadibloc.com/comp/cp0301.htm

I make a comment on the contrast between the instruction sets of the
IBM 701 computer and the PDP-8, in that subroutine call and loop
instructions were found to be more important, and were given more
prominence, in the later PDP-8.

But in general, the changes in computer ISAs have not been reflected
in computer languages in any recognizable fashion.

One exception to this is the generally short-lived attempt to build
computers with instruction sets oriented towards higher-level language
execution. The Burroughs architecture still survives, though, and
there are also processors designed to directly execute Java bytecode.

And I suppose one might also want to look at the VAX.

And then there's LISP and the LISP machines.

So I hope I've given you some hints on where to start looking, but the
connection between computer ISAs and computer languages is tenuous at
best.

Thus, the IBM 1401, the IBM 7090, and the IBM 360 had very different
ISAs - the IBM 360 trying to basically combine the strengths of the
previous two architectures - but they all ran COBOL and FORTRAN.

PL/I was added for the 360; it was a bigger language for a bigger and
more powerful machine. But how much did the ISA really have to do with
it?

John Savard

[lawr...@gandi.cluon.com]

"Charles Richmond" <nume...@aquaporin4.com> writes:
>>
>
> I have programmed in C for circa 20 years... and I have yet to even
> use a bitfield in a structure. I would wager that the bitfield is
> seldom used by most C programmers. I did *once* have the occasion to
> use the setjmp/longjmp facility.
>

I've used it in two places in my life (bitfields, not setjmp/longjmp -
which I've also used "about twice" but can't recall exactly where).

Both were "embedded"ish applications - one for the Sega Genesis, where
we used bitfields just to map the fields in the hardware registers for
the video stuff into C structures. This was more than just syntactic
sugar, because the code could produce sprite tables at run time on the
stack and then call a service routine that would enqueue a DMA for the
next vblank interval. (I still have all of the libraries we wrote for
that platform, now running under GCC 4.x and occasionally write code to
run under an emulated Genesis. $DEITY how I loved that platform.)

The other was a C for an 8051-variant where there was so little memory
available at run time (1K IIRC) that using a whole byte to hold a
1-bit flag (which I would readily do without thinking on a modern
"hosted" implementation) would have made our project not work. As it
was, when I left the project in 1997, there were only four bytes free at
run time and a list of features that were all deferred because they
needed more than 4 bytes to implement.

--NK1G

[Rich Alderson]

"Charles Richmond" <nume...@aquaporin4.com> writes:

> "Walter Bushell" <pr...@panix.com> wrote in message
> news:proto-E473C6....@news.panix.com...

>> Consider writing a C compiler for the DEC 10, which was very byte
>> friendly for a word oriented machine.

> There *is* a C compiler for the PDP-10/DEC-20. It used 9-bit bytes.

One of them does. There's more than one C compiler for TOPS-20.

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

[Shmuel Metz]

In <20121011133209.cb79...@eircom.net>, on 10/11/2012

at 01:32 PM, Ahem A Rivet's Shot <ste...@eircom.net> said:

>I did meet an Algol68 compiler that compiled for CP/M

Ouch!

[Peter Flass]

I believe there was one, or are you just asking him to think about what
it involved?

--
Pete

[Peter Flass]

Likewise there's a Multics C compiler for Honeywell DPS-68 machines,
though I don't know the details.

--
Pete

[Peter Flass]

On 10/11/2012 12:22 PM, Ahem A Rivet's Shot wrote:
> On Thu, 11 Oct 2012 09:19:32 -0500
> "Charles Richmond" <nume...@aquaporin4.com> wrote:
>
>> "Ahem A Rivet's Shot" <ste...@eircom.net> wrote in message
>> news:20121011133209.cb79...@eircom.net...
>>> On Thu, 11 Oct 2012 07:43:00 -0400
>>> Peter Flass <Peter...@Yahoo.com> wrote:
>
>>> The first CP/M C compiler I used was a cut down implementation.
>>> They left out bitfields among other things (unions too I think). It's a
>>> pity
>>> that the code I'd written while waiting for the compiler to arrive was
>>> littered with bitfields.
>>>
>>
>> I have programmed in C for circa 20 years... and I have yet to even use a
>> bitfield in a structure. I would wager that the bitfield is seldom used
>> by most C programmers. I did *once* have the occasion to use the
>> setjmp/longjmp facility.
>
> Yes, well I was writing a table driven assembler/disassembler. It
> seemed like a good idea to make the definition tables good and tight. I've
> also used them for packing status fields into words when I want to be
> stingy with memory.
>

C does a really bad job with bit structures compared to PL/I. I often
use bit strings extensively in PL/I. When writing the Iron Spring
compiler I spent a lot of time - overspent really - trying to optimize
them as much as possible.

--
Pete

[Peter Flass]

On 10/11/2012 1:41 PM, Quadibloc wrote:
>
> As to the relationship between the evolution of computer instruction
> sets and computer languages -
>
> well, there isn't much of a relation.
>
> On my web site, at
>
> http://www.quadibloc.com/comp/cp0301.htm
>
> I make a comment on the contrast between the instruction sets of the
> IBM 701 computer and the PDP-8, in that subroutine call and loop
> instructions were found to be more important, and were given more
> prominence, in the later PDP-8.
>
> But in general, the changes in computer ISAs have not been reflected
> in computer languages in any recognizable fashion.

The influence is the other way. I believe C's stupid null-terminated
strings were developed because of the instruction set of the PDP-11, but
System z has added a set of instructions to handle these mostly because
of C. Likewise IBM has now added decimal floating point, which PL/I has
had since the beginning but which had to be simulated before.

>
> One exception to this is the generally short-lived attempt to build
> computers with instruction sets oriented towards higher-level language
> execution. The Burroughs architecture still survives, though, and
> there are also processors designed to directly execute Java bytecode.

iAPX432.




--
Pete

[Anne & Lynn Wheeler]

Peter Flass <Peter...@Yahoo.com> writes:
> The influence is the other way. I believe C's stupid null-terminated
> strings were developed because of the instruction set of the PDP-11,
> but System z has added a set of instructions to handle these mostly
> because of C. Likewise IBM has now added decimal floating point,
> which PL/I has had since the beginning but which had to be simulated
> before.

modulo cps microcode mod for 360/50 ... recent post
http://www.garlic.com/~lynn/2012n.html#26 Is there a correspondence between 64-bit IBM mainframes and PoOps editions levels?

allen-babcock progress report
http://www.bitsavers.org/pdf/allen-babcock/cps/CPS_Progress_Report_may66.pdf

--
virtualization experience starting Jan1968, online at home since Mar1970

[hanc...@bbs.cpcn.com]

On Oct 11, 3:22 am, Nick Spalding <spald...@iol.ie> wrote:

> In the Education Center (or whatever it was called) at Poughkeepsie
> where I was learning the 7010 at the time.  We all got the day off, it
> wouldn't have been proper for us to see them dishing out the demon
> alcohol to all the journalists.

Would you recall the difference between the 7010 and the 1410? To me,
based on manuals, they seem to be very similar machines. Thanks.

[hanc...@bbs.cpcn.com]

The 1401 is a good choice to start. As you mentioned, there is a
simulator available. The 1401 has a basic instruction.

[Bill Leary]

"Peter Flass" wrote in message news:k57m14$dqv$1...@dont-email.me...

Wow, someone else remembers the '432.

Also, the Western Digital Pascal Micro-engine.

- Bill

[hanc...@bbs.cpcn.com]

On Oct 11, 7:36 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> > The history of programming languages and the history of CPU are two
> > separate issues.  They developed separately.
>
> They really did develop in tandem.  Why was Autocoder the most popular
> language on 14xx machines?  COBOL was available at the time, why not use
> it?  One big reason is the time it took to compile a COBOL program, the
> system wasn't big or fast enough.  Look at IBM's OS/360 compilers - why
> did they have multiple versions like FORTRAN D, FORTRAN E, FORTRAN H,
> etc.?  Because memory was a major restriction and they had to trade-off

> features and capability in order to get the compiler to fit.  . . .

That is all true. Compilers needed more horsepower.

But high level languages were independent of CPUs. For instance,
Fortran was developed by IBM, yet by many others, and used on a
variety of machines. COBOL was developed by an industry trade group.
The languages could, if really wanted, run on the smaller machines.
(I believe some Fortran programs were "pre screned" on 1401s used as a
spooler to the 7090).

[hanc...@bbs.cpcn.com]

On Oct 11, 1:41 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:


> But higher-level language programming took off when FORTRAN was
> written for the IBM 704, because that compiler had optimizing features
> that meant that programs were competitive with those written in
> assembler language. (At that time, computer time cost hundreds of
> dollars per hour, and computers were much less powerful than they are
> today, so computer time cost much more than people time in writing
> programs.)

Hardware costs were seen as more expensive than programmers well into
the 1980s, not just the 1950s. Even with S/360, a lot of work was
done in assembler in the 1960s since machines were too small.

[Louis Krupp]

On Wed, 10 Oct 2012 04:42:04 +0000 (UTC), Rajib Kumar Bandopadhyay
<bkpsu...@gmail.com> wrote:

>Dear friends,
>I am a subscriber of comp.unix.shell. I was directed to your usergroup by
>Dan Espen. I posted the following email to that group:
>=======================================================
>I have been toying with an idea for a long time. How can I delve into the

>history of Programming language and CPU - how to watch with my own eyes
>and understand their demerits?
>

>I know there are many links on the web, like
>http://en.wikipedia.org/wiki/Timeline_of_programming_languages ,
>http://en.wikipedia.org/wiki/Analytical_engine and others, but how to
>watch things happening in an actual machine, learn how to program it and
>then understanding the earlier paradigm by programming it myself.
>Just like I have learnt the basics of physics and mathematics by first
>principles, I wish to follow the same route by delving into history and
>operations of these computational machines.
>I am being naive, but will someone help me on this? Since you guys are
>deeply into coding you would be the best ones to guide me on this?
>=======================================================
>Hope you help me regarding this. I found way too much information in your
>group, beyond my level of comprehension and also randomly scattered
>across the group-discussions.
>

<snip>

On August 28th, Charles Richmond posted the following. The book he
mentions might be useful.

==================

On this group, we often discuss the sad state of the CS community and
how
newbie programmers do *not* even understand what RAM memory and
assembly
language is all about. Well, *maybe* there is hope after all! I
stumbled
across a book that could impart such knowledge, from MIT *no* less,
and if
universities pick this up... perhaps the next generation of Computer
Scientists will know more about where computers have been in the past
and
how they *really* function.

The book is titled _The Elements of Computing Systems: Building a
Modern
Computer from First Principles_, by Noam Nisan and Shimon Schocken,
2005,
MIT Press, ISBN-10: 0262640686, ISBN-13: 978-0262640688. The second
edition came out in 2009. The book has a picture of a little boy on
the
cover holding an abacus.

The web site for the book is:

http://www1.idc.ac.il/tecs/

This website has downloadable lesson plans and software for use with
the
book with a Q&A forum and a link to the pdf of a syllabus for
Stanford's
course CS116: From Nand to Tetris.

This is a very hopeful sign. :-)

--

numerist at aquaporin4 dot com

==================

Louis

[Rajib Kumar Bandopadhyay]

On Thu, 11 Oct 2012 19:52:03 -0400, Peter Flass wrote:
> C does a really bad job with bit structures compared to PL/I. I often
> use bit strings extensively in PL/I. When writing the Iron Spring
> compiler I spent a lot of time - overspent really - trying to optimize
> them as much as possible.

Does that mean PL/I can still be used in place of C? That is supposed to
be anachronistic?!

[Rajib Kumar Bandopadhyay]

On Thu, 11 Oct 2012 13:34:42 +0000, jmfbahciv wrote:
> Honey, you can't stop a rock which has started rolling down hill. In
> this newsgroups, topics ramble in seemingly unrelated areas. However,
> if you read closely, it all has something to do with how we did our
> work.

Actually, on hindsight, I am sorry I said that. I am flooded with so much
information, you know, and am rather happy for this! I will collect my
doubts and post them later on when I have begun understanding what I have
taken in.

[Nick Spalding]

hanc...@bbs.cpcn.com wrote, in
<f77db771-9d68-4de2...@m5g2000yql.googlegroups.com>
on Thu, 11 Oct 2012 18:06:52 -0700 (PDT):

Programming-wise they were virtually identical, I have a vague
recollection of an extra instruction or two being available for the
7010.

The big difference was speed. The 1410 had a cycle time of 4.5µsecs per
character; the 7010 had a read/rewrite cycle of 1.8µsecs, and a
read/process/rewrite cycle of 2.4µsecs, both being for two characters,
at an even/odd pair of addresses. Since there was no alignment
restriction in the programming this meant there was some pretty fancy
footwork in the instruction decoding and addressing hardware.

A minor difference was that the 1410 had a maximum memory size of 80k
characters while the 7010 as standard could go to 100k. The machine we
were going to have would have had an extra 100k using the 1401 zone bit
trick to address it. A character of course was just as in the 1401,
parity, word mark, BA8421. The system was cancelled as the customer,
Aer Lingus, decided to wait for a 360/50.
--
Nick Spalding

[Nick Spalding]

hanc...@bbs.cpcn.com wrote, in
<d3f91df1-d8b7-4bee...@y1g2000yqg.googlegroups.com>
on Thu, 11 Oct 2012 18:25:34 -0700 (PDT):

The last assembler programs I wrote were for a very small 370 (115?) in
1973.
--
Nick Spalding

[Peter Flass]

And Assembler was a lot more fun!


--
Pete

[Peter Flass]

"It all depends(tm)" PL/I is alive and well. C outgrew its original
basis as a high-level assembler, and all kinds of cruft was added, both
to the language and the libraries, in various incompatible ways. PL/I
started big, and has not needed to have a lot added.

Multics was entirely written in PL/I. More recently Iron Spring PL/I is
almost entirely PL/I with a couple of small assembler bits in the
library, and no C.


--
Pete

[Bob Martin]

I was still programming in assembler up to the day I finally retired in 2003.
Have done a little since, for fun, on Hercules VM/370.

[Bob Martin]

in 580241 20121012 090435 Nick Spalding <spal...@iol.ie> wrote:
>hanc...@bbs.cpcn.com wrote, in
><f77db771-9d68-4de2...@m5g2000yql.googlegroups.com>
>on Thu, 11 Oct 2012 18:06:52 -0700 (PDT):
>
>> On Oct 11, 3:22�am, Nick Spalding <spald...@iol.ie> wrote:
>>
>> > In the Education Center (or whatever it was called) at Poughkeepsie
>> > where I was learning the 7010 at the time. �We all got the day off, it
>> > wouldn't have been proper for us to see them dishing out the demon
>> > alcohol to all the journalists.
>>
>> Would you recall the difference between the 7010 and the 1410? To me,
>> based on manuals, they seem to be very similar machines. Thanks.
>
>Programming-wise they were virtually identical, I have a vague
>recollection of an extra instruction or two being available for the
>7010.
>

>The big difference was speed. The 1410 had a cycle time of 4.5�secs per
>character; the 7010 had a read/rewrite cycle of 1.8�secs, and a
>read/process/rewrite cycle of 2.4�secs, both being for two characters,

>at an even/odd pair of addresses. Since there was no alignment
>restriction in the programming this meant there was some pretty fancy
>footwork in the instruction decoding and addressing hardware.
>
>A minor difference was that the 1410 had a maximum memory size of 80k
>characters while the 7010 as standard could go to 100k. The machine we
>were going to have would have had an extra 100k using the 1401 zone bit
>trick to address it. A character of course was just as in the 1401,
>parity, word mark, BA8421. The system was cancelled as the customer,
>Aer Lingus, decided to wait for a 360/50.

I still have my maroon CE handbook for the 1410. My most vivid memory of that
system was typing in the IPL sequence on the 1052. Any others do that?

[Walter Bushell]

In article <k57kj4$5p2$1...@dont-email.me>,

Mostly the latter. I suppose nine bit bytes would be the best
compromise, but that's off the top of my head. That would still lead
to problems, for example, ints and longs would not overflow when they
should, etcetera. The standards would allow it, but I think the
standard libraries are written assuming 8 bit bytes.

--
This space unintentionally left blank.

[Walter Bushell]

In article <k57m14$dqv$1...@dont-email.me>,

Peter Flass <Peter...@Yahoo.com> wrote:

> The influence is the other way. I believe C's stupid null-terminated
> strings were developed because of the instruction set of the PDP-11,

And C was developed in a very different environment. C was designed
for systems with controlled access, not wide open world wide access
and controlling actual ca$h.

[Dan Espen]

Bob Martin <bob.m...@excite.com> writes:

> in 580242 20121012 091309 Nick Spalding <spal...@iol.ie> wrote:
>>hanc...@bbs.cpcn.com wrote, in
>><d3f91df1-d8b7-4bee...@y1g2000yqg.googlegroups.com>
>>on Thu, 11 Oct 2012 18:25:34 -0700 (PDT):
>>

>>> On Oct 11, 1:41�pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
>>>
>>>
>>> > But higher-level language programming took off when FORTRAN was
>>> > written for the IBM 704, because that compiler had optimizing features
>>> > that meant that programs were competitive with those written in
>>> > assembler language. (At that time, computer time cost hundreds of
>>> > dollars per hour, and computers were much less powerful than they are
>>> > today, so computer time cost much more than people time in writing
>>> > programs.)
>>>
>>> Hardware costs were seen as more expensive than programmers well into
>>> the 1980s, not just the 1950s. Even with S/360, a lot of work was
>>> done in assembler in the 1960s since machines were too small.
>>
>>The last assembler programs I wrote were for a very small 370 (115?) in
>>1973.
>
> I was still programming in assembler up to the day I finally retired in 2003.
> Have done a little since, for fun, on Hercules VM/370.

The last 360 assembler I wrote, was ... well, right now.
Just did a make, waiting for the compile/test results.

--
Dan Espen

[jmfbahciv]

Rajib Kumar Bandopadhyay wrote:
> On Thu, 11 Oct 2012 13:34:42 +0000, jmfbahciv wrote:
>> Honey, you can't stop a rock which has started rolling down hill. In
>> this newsgroups, topics ramble in seemingly unrelated areas. However,
>> if you read closely, it all has something to do with how we did our
>> work.
> Actually, on hindsight, I am sorry I said that. I am flooded with so much
> information, you know, and am rather happy for this!

There are a hundred people who have different experiences with alsmot
the whole range of hard/software. Some even were doing the development
of that stuff. Others used it and created marvelous computing environments.
To absorb everything we "know" is impossible. Choose an architecture you
like, then play with it. There are emulators for most things. I'm biased
so I don't want to give you a recommendation of architecture.

> I will collect my
> doubts and post them later on when I have begun understanding what I have
> taken in.

Go ahead and post the questions. In my business, there was no such thing
as a stupid question, unless it's repeated for the sole purpose of delaying
work.

/BAH

[jmfbahciv]

hanc...@bbs.cpcn.com wrote:
> On Oct 11, 7:36 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
>
>> > The history of programming languages and the history of CPU are two
>> > separate issues.  They developed separately.
>>
>> They really did develop in tandem.  Why was Autocoder the most popular
>> language on 14xx machines?  COBOL was available at the time, why not use
>> it?  One big reason is the time it took to compile a COBOL program, the
>> system wasn't big or fast enough.  Look at IBM's OS/360 compilers - why
>> did they have multiple versions like FORTRAN D, FORTRAN E, FORTRAN H,
>> etc.?  Because memory was a major restriction and they had to trade-off
>> features and capability in order to get the compiler to fit.  . . .
>
> That is all true. Compilers needed more horsepower.
>
> But high level languages were independent of CPUs.

Wrong. Not at the time the first compilers/interpreters were written.
EAch one was written to solve a particular problem for the people
who were working on a particular machine. COBOL is an example.
Even the HLLs which were written as a univerity exercise/class was
tied to a particular machine. You can tell (usually) which machine
it was from the decisions made when implemented.

If a compiler was useful enough, the compiler was implemented on
more architectures. That's when the Standards committed get formed
to write a functional spec for the entire industry.

> For instance,
> Fortran was developed by IBM, yet by many others, and used on a
> variety of machines. COBOL was developed by an industry trade group.
> The languages could, if really wanted, run on the smaller machines.
> (I believe some Fortran programs were "pre screned" on 1401s used as a
> spooler to the 7090).

FORTAN II was available on the 1620.

/BAH

[jmfbahciv]

Louis Krupp wrote:
> On Wed, 10 Oct 2012 04:42:04 +0000 (UTC), Rajib Kumar Bandopadhyay
> <bkpsu...@gmail.com> wrote:

<snip>

Louis--would pointing at _Introduction to Programming_ by Digial's
Small Computer Handbook Series help? It's very detailed so I usually
point someone at it who wants to learn how to code, not learn an overview.

> This is a very hopeful sign. :-)
>

Yes. The OP may choke on all the bits we're throwing at him. Even
the human brain has memory limits.

/BAH

[jmfbahciv]

Bob Martin wrote:
> in 580242 20121012 091309 Nick Spalding <spal...@iol.ie> wrote:
>>hanc...@bbs.cpcn.com wrote, in
>><d3f91df1-d8b7-4bee...@y1g2000yqg.googlegroups.com>
>>on Thu, 11 Oct 2012 18:25:34 -0700 (PDT):
>>

>>> On Oct 11, 1:41�pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
>>>
>>>
>>> > But higher-level language programming took off when FORTRAN was
>>> > written for the IBM 704, because that compiler had optimizing features
>>> > that meant that programs were competitive with those written in
>>> > assembler language. (At that time, computer time cost hundreds of
>>> > dollars per hour, and computers were much less powerful than they are
>>> > today, so computer time cost much more than people time in writing
>>> > programs.)
>>>
>>> Hardware costs were seen as more expensive than programmers well into
>>> the 1980s, not just the 1950s. Even with S/360, a lot of work was
>>> done in assembler in the 1960s since machines were too small.
>>
>>The last assembler programs I wrote were for a very small 370 (115?) in
>>1973.
>
> I was still programming in assembler up to the day I finally retired in
2003.

Kewl. Which assembler?

> Have done a little since, for fun, on Hercules VM/370.

Once it's in your blood, doing HLLs is lowering yourself ;-)

/BAH

[Nick Spalding]

Bob Martin wrote, in <adqg5p...@mid.individual.net>
on Fri, 12 Oct 2012 13:19:03 BST:

> in 580241 20121012 090435 Nick Spalding <spal...@iol.ie> wrote:
> >hanc...@bbs.cpcn.com wrote, in
> ><f77db771-9d68-4de2...@m5g2000yql.googlegroups.com>
> >on Thu, 11 Oct 2012 18:06:52 -0700 (PDT):
> >
> >> On Oct 11, 3:22ï¿œam, Nick Spalding <spald...@iol.ie> wrote:
> >>
> >> > In the Education Center (or whatever it was called) at Poughkeepsie

> >> > where I was learning the 7010 at the time. ï¿œWe all got the day off, it

> >> > wouldn't have been proper for us to see them dishing out the demon
> >> > alcohol to all the journalists.
> >>
> >> Would you recall the difference between the 7010 and the 1410? To me,
> >> based on manuals, they seem to be very similar machines. Thanks.
> >
> >Programming-wise they were virtually identical, I have a vague
> >recollection of an extra instruction or two being available for the
> >7010.
> >

> >The big difference was speed. The 1410 had a cycle time of 4.5ï¿œsecs per
> >character; the 7010 had a read/rewrite cycle of 1.8ï¿œsecs, and a
> >read/process/rewrite cycle of 2.4ï¿œsecs, both being for two characters,

> >at an even/odd pair of addresses. Since there was no alignment
> >restriction in the programming this meant there was some pretty fancy
> >footwork in the instruction decoding and addressing hardware.
> >
> >A minor difference was that the 1410 had a maximum memory size of 80k
> >characters while the 7010 as standard could go to 100k. The machine we
> >were going to have would have had an extra 100k using the 1401 zone bit
> >trick to address it. A character of course was just as in the 1401,
> >parity, word mark, BA8421. The system was cancelled as the customer,
> >Aer Lingus, decided to wait for a 360/50.
>
> I still have my maroon CE handbook for the 1410. My most vivid memory of that
> system was typing in the IPL sequence on the 1052. Any others do that?

I didn't have to on the 7010, they had come to their senses and put back
the Load button.
--
Nick Spalding

[Charles Richmond]

"Rich Alderson" <ne...@alderson.users.panix.com> wrote in message
news:mddehl4...@panix5.panix.com...
> "Charles Richmond" <nume...@aquaporin4.com> writes:
>
>> "Walter Bushell" <pr...@panix.com> wrote in message
>> news:proto-E473C6....@news.panix.com...

>
>>> Consider writing a C compiler for the DEC 10, which was very byte
>>> friendly for a word oriented machine.
>

>> There *is* a C compiler for the PDP-10/DEC-20. It used 9-bit bytes.
>
> One of them does. There's more than one C compiler for TOPS-20.
> I guess my only exposure to a TOPS-20 compiler... is the compiler on
> Xkleten. :-)

[Ahem A Rivet's Shot]

On Thu, 11 Oct 2012 19:57:43 -0400
Peter Flass <Peter...@Yahoo.com> wrote:

> The influence is the other way. I believe C's stupid null-terminated
> strings were developed because of the instruction set of the PDP-11, but

C's stupid null terminated strings are what make highly efficient
(in time and memory) things like strtok possible. These days there's memory
and cycles to burn on string shuffling and copying, but then it was best
avoided if at all possible.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[Charles Richmond]

"Dan Espen" <des...@verizon.net> wrote in message
news:ick3uxy...@home.home...
> "Charles Richmond" <nume...@aquaporin4.com> writes:
>
>> "Ahem A Rivet's Shot" <ste...@eircom.net> wrote in message
>> news:20121011133209.cb79...@eircom.net...

>>> On Thu, 11 Oct 2012 07:43:00 -0400
>>> Peter Flass <Peter...@Yahoo.com> wrote:
>>>
>>>> They really did develop in tandem. Why was Autocoder the most popular
>>>> language on 14xx machines? COBOL was available at the time, why not
>>>> use
>>>> it? One big reason is the time it took to compile a COBOL program, the
>>>> system wasn't big or fast enough. Look at IBM's OS/360 compilers - why
>>>> did they have multiple versions like FORTRAN D, FORTRAN E, FORTRAN H,
>>>> etc.? Because memory was a major restriction and they had to trade-off

>>>> features and capability in order to get the compiler to fit. This is
>>>> probably the biggest factor why C and not PL/I became popular on
>>>> micros,
>>>
>>> The first CP/M C compiler I used was a cut down implementation.
>>> They left out bitfields among other things (unions too I
>>> think). It's a pity
>>> that the code I'd written while waiting for the compiler to arrive was
>>> littered with bitfields.
>>>
>>
>> I have programmed in C for circa 20 years... and I have yet to even
>> use a bitfield in a structure. I would wager that the bitfield is
>> seldom used by most C programmers. I did *once* have the occasion to
>> use the setjmp/longjmp facility.
>
> A bit makes an ideal yes or no type switch, but if I'm writing everyday
> application code, I'll create a "YORN" instead. (A character field
> containing a Y OR N.)
>
> When you're not writing everyday code, things change.
>
> The Fvwm window manager (for X11), has a huge number of options that
> can be set for different types of windows, (in Fvwm terms, Style
> options). Most of these are represented by bits in a rather large
> bit structure.
>
> When this was designed, we were concerned that the compiler might be
> inefficient testing a single bit in a large array of bits compared to
> testing a character so we examined the generated code for setting and
> testing bits on a number of platforms, with different compilers.
> Turned out C does a pretty good job working with large bit structures.
>

Yes, at a PPoE, I have used a large integer array that acted as one big bit
mask. But it was *not* a bitfield in a structure. After determining which
element of the array contains the bit to be tested... one only needs to
shift a 1 into a position in a mask to test the bit. Pretty effecient.

[Rajib Kumar Bandopadhyay]

On Fri, 12 Oct 2012 14:04:45 +0000, jmfbahciv wrote:

> I'm biased
> so I don't want to give you a recommendation of architecture.

No, please go ahead and recommend. I am happily gathering gemstones!

[Rajib Kumar Bandopadhyay]

On Fri, 12 Oct 2012 14:04:51 +0000, jmfbahciv wrote:

> Even
> the human brain has memory limits.

No problem, you all just flow. I will take time, but ultimately grasp
these. Please don't stop!

[Rajib Kumar Bandopadhyay]

On Fri, 12 Oct 2012 14:04:52 +0000, jmfbahciv wrote:

> Once it's in your blood, doing HLLs is lowering yourself ;-)

What does your statement mean with the smiley? Just remember I am a
little dim in wit.

[Rajib Kumar Bandopadhyay]

On Fri, 12 Oct 2012 14:40:22 +0000, Rajib Kumar Bandopadhyay wrote:

> On Fri, 12 Oct 2012 10:00:28 -0400, Dan Espen wrote:
>
>> was ... well, right now.

> What is the utility of programming in assembly? Please elaborate...

No, I mean, the present time. I remember that assembly was better when
CPU time was expensive, and the process of recompilation took a lot of
time... Why now? Does it mean it still is?

[Shmuel Metz]

In <k58vr0$hl4$1...@dont-email.me>, on 10/12/2012

at 07:51 AM, Peter Flass <Peter...@Yahoo.com> said:

>"It all depends(tm)" PL/I is alive and well. C outgrew its original
> basis as a high-level assembler,

C was never a high level assembler, but most code in an OS doesn't
require the use of arbitrary instructions.

>Multics was entirely written in PL/I.

No; some[1] parts were written in ALM. OTOH, all of the MCP for the
B5000 was written in ALGOL-60 dialects[1].

[1] Following a redesign, some pieces that were originally in
ALM were rewritten in PL/I and turned out to be faster than the
ALM version; it pays to worry about the algorithms before
tweaking the code.

[2] But note that ESPOL had specialized statements for all of
the operation syllables of the machine.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Shmuel Metz]

In <k58f1c$m13$1...@dont-email.me>, on 10/12/2012

at 06:57 AM, Rajib Kumar Bandopadhyay <bkpsu...@gmail.com> said:

>Does that mean PL/I can still be used in place of C? That is
>supposed to be anachronistic?!

A Trabant is a newer car than a Rolls Royce Silver Cloud. PL/I is a
much better language than C, just harder to implement on a PDP-7.

[Shmuel Metz]

In <k57m14$dqv$1...@dont-email.me>, on 10/11/2012

at 07:57 PM, Peter Flass <Peter...@Yahoo.com> said:

>The influence is the other way. I believe C's stupid
>null-terminated strings were developed because of the instruction
>set of the PDP-11,

No, but the ++ and -- operations appear to have been added because of
the increment and decrement operations on the PDP-7.

>iAPX432.

That was a capability-based architecture. It was certainly high level,
but I don't know of anything in it to support a specific language.

[Charles Richmond]

"Quadibloc" <jsa...@ecn.ab.ca> wrote in message
news:048768e7-220a-4039...@b4g2000pby.googlegroups.com...
On Oct 9, 10:42 pm, Rajib Kumar Bandopadhyay <bkpsusmi...@gmail.com>
wrote:
>> How can I delve into the
>> history of Programming language and CPU - how to watch with my own eyes
>> and understand their demerits?
>
>As to the relationship between the evolution of computer instruction
>sets and computer languages -
>
>well, there isn't much of a relation.

Yes, I agree with you... in general there is *not* much of a relation
between computer languages and CPU instructions developed for them. One
exception woud be the Edit (ED) and Edit and Mark (EDMK) instructions on the
IBM 370. These instructions seemed designed especially for implementing
parts of COBOL.

[Rajib Kumar Bandopadhyay]

On Wed, 10 Oct 2012 18:41:23 -0700, Al Kossow wrote:

> re. programming
What is meant by this. Please explain.

[Charles Richmond]

"Peter Flass" <Peter...@Yahoo.com> wrote in message
news:k57m14$dqv$1...@dont-email.me...

> On 10/11/2012 1:41 PM, Quadibloc wrote:
>>
>> As to the relationship between the evolution of computer instruction
>> sets and computer languages -
>>
>> well, there isn't much of a relation.
>>

>> On my web site, at
>>
>> http://www.quadibloc.com/comp/cp0301.htm
>>
>> I make a comment on the contrast between the instruction sets of the
>> IBM 701 computer and the PDP-8, in that subroutine call and loop
>> instructions were found to be more important, and were given more
>> prominence, in the later PDP-8.
>>
>> But in general, the changes in computer ISAs have not been reflected
>> in computer languages in any recognizable fashion.

>
> The influence is the other way. I believe C's stupid null-terminated

> strings were developed because of the instruction set of the PDP-11, but
> System z has added a set of instructions to handle these mostly because of
> C. Likewise IBM has now added decimal floating point, which PL/I has had
> since the beginning but which had to be simulated before.
>

I find C's null terminated strings *not* to be a burden. It becomes a
problem only when dealing with binary data that sometimes contains zero
bytes. But then, *strings* are supposed to be characters. ISTM that the
Tahoe architecture also had an instruction that would count the bytes in a
string. You put the address of the string in a certain register and issued
the instruction.

>>
>> One exception to this is the generally short-lived attempt to build
>> computers with instruction sets oriented towards higher-level language
>> execution. The Burroughs architecture still survives, though, and
>> there are also processors designed to directly execute Java bytecode.
>
> iAPX432.
>

Which was a resounding failure. ISTM that the iAPX432 was too ambitious for
the "state of the art" chip development at the time.

[Charles Richmond]

"Nick Spalding" <spal...@iol.ie> wrote in message
news:etjf789q7qc5s5ham...@4ax.com...
> hanc...@bbs.cpcn.com wrote, in
> <d3f91df1-d8b7-4bee...@y1g2000yqg.googlegroups.com>
> on Thu, 11 Oct 2012 18:25:34 -0700 (PDT):

>
>> On Oct 11, 1:41 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
>>
>>
>> > But higher-level language programming took off when FORTRAN was
>> > written for the IBM 704, because that compiler had optimizing features
>> > that meant that programs were competitive with those written in
>> > assembler language. (At that time, computer time cost hundreds of
>> > dollars per hour, and computers were much less powerful than they are
>> > today, so computer time cost much more than people time in writing
>> > programs.)
>>
>> Hardware costs were seen as more expensive than programmers well into
>> the 1980s, not just the 1950s. Even with S/360, a lot of work was
>> done in assembler in the 1960s since machines were too small.
>
> The last assembler programs I wrote were for a very small 370 (115?) in
> 1973.
>

Embedded programmers probably *still* use asembly in some cases. The last
real assembly language I did was for the Z8000 in 1991 at a PPoE.

[Charles Richmond]

<lawr...@gandi.cluon.com> wrote in message
news:87391k2...@gandi.cluon.com...

> "Charles Richmond" <nume...@aquaporin4.com> writes:
>>>
>>
>> I have programmed in C for circa 20 years... and I have yet to even
>> use a bitfield in a structure. I would wager that the bitfield is
>> seldom used by most C programmers. I did *once* have the occasion to
>> use the setjmp/longjmp facility.
>>
>

> I've used it in two places in my life (bitfields, not setjmp/longjmp -
> which I've also used "about twice" but can't recall exactly where).
>
> Both were "embedded"ish applications - one for the Sega Genesis, where
> we used bitfields just to map the fields in the hardware registers for
> the video stuff into C structures. This was more than just syntactic
> sugar, because the code could produce sprite tables at run time on the
> stack and then call a service routine that would enqueue a DMA for the
> next vblank interval. (I still have all of the libraries we wrote for
> that platform, now running under GCC 4.x and occasionally write code to
> run under an emulated Genesis. $DEITY how I loved that platform.)
>

By "bitfields" we are talking about a bitfield that exists in a structure...
*not* just a byte used as an "array" of bits. You'd better be careful using
bit fields for hardware registers... the exact placement of the bitfields is
implimentation specific (according to the C standard). Use a different C
compiler and you could get royally screwed!!!

> The other was a C for an 8051-variant where there was so little memory
> available at run time (1K IIRC) that using a whole byte to hold a
> 1-bit flag (which I would readily do without thinking on a modern
> "hosted" implementation) would have made our project not work. As it
> was, when I left the project in 1997, there were only four bytes free at
> run time and a list of features that were all deferred because they
> needed more than 4 bytes to implement.
>

I worked with a guy at a PPoE on an embedded MC6800 (that's the 8-bit
processor) code written in assembly. The processor was built by Hitachi,
who at one point licensed some of the Motorola 8-bit processors. The chip
had 128 bytes of on-board RAM... and that was *all* the RAM used, *no* other
RAM chips. One had to be *very* careful about subroutine call levels and
leaving enough room in the stack for an interrupt service to happen, which
automatically pushed a lot of registers.

[Dan Espen]

Rajib Kumar Bandopadhyay <bkpsu...@gmail.com> writes:

> On Fri, 12 Oct 2012 10:00:28 -0400, Dan Espen wrote:
>

>> was ... well, right now.

> What is the utility of programming in assembly? Please elaborate...

1. The existing system is already 90% assembler.
2. Performance is critical.
3. The applications database is full of length prefixed variable length
fields. Easier to process in Assembler.

--
Dan Espen

[Charles Richmond]

"Nick Spalding" <spal...@iol.ie> wrote in message

news:lbif78tnmi169p044...@4ax.com...
>
> [snip...] [snip...]
> [snip...]

>
> A minor difference was that the 1410 had a maximum memory size of 80k
> characters while the 7010 as standard could go to 100k. The machine we
> were going to have would have had an extra 100k using the 1401 zone bit
> trick to address it. A character of course was just as in the 1401,
> parity, word mark, BA8421. The system was cancelled as the customer,
> Aer Lingus, decided to wait for a 360/50.
>

If you got to work on the IBM 360/50, you were much better prepared for
future employment... than with more years of experience on the 1410/7010.
IMHO. :-)

[Shmuel Metz]

In <20121012151512.5dfb...@eircom.net>, on 10/12/2012

at 03:15 PM, Ahem A Rivet's Shot <ste...@eircom.net> said:

>C's stupid null terminated strings are what make highly efficient (in
>time and memory) things like strtok possible.

How is it more efficient with a null-terminated string than with a
string that includes a length field? In fact, how is it even equally
efficient? Consider the code to concatenate two strings.

[Shmuel Metz]

In <PM0004CBD...@ac81381f.ipt.aol.com>, on 10/12/2012

at 02:04 PM, jmfbahciv <See....@aol.com> said:

>Once it's in your blood, doing HLLs is lowering yourself ;-)

I've been doing assembler programming since 1960, and I happily use a
high-level language when it is appropriate for the problem at hand.
However, I'll admit to writing assembler subroutines callable from,
e.g., FORTRAN, PL/I, REXX.

[Shmuel Metz]

In <PM0004CBD...@ac81381f.ipt.aol.com>, on 10/12/2012
at 02:04 PM, jmfbahciv <See....@aol.com> said:

>Wrong. Not at the time the first compilers/interpreters were
>written. EAch one was written to solve a particular problem for the
>people who were working on a particular machine. COBOL is an
>example.

Not even close; the C in COBOL stands for common. Your statement may
be true of compilers prior to FORTRAN, but is certainly wrong for,
e.g., ALGOL 58, ALGOL 60, COBOL.

[Shmuel Metz]

In <icfw5jz...@home.home>, on 10/12/2012
at 10:00 AM, Dan Espen <des...@verizon.net> said:

>The last 360 assembler I wrote, was ... well, right now.

360? I could understand Assembler (XF) if you're using Hercules to
run, e.g., MVS, but why S/360?

[Shmuel Metz]

In <adqg5p...@mid.individual.net>, on 10/12/2012

at 01:19 PM, Bob Martin <bob.m...@excite.com> said:

>I still have my maroon CE handbook for the 1410. My most vivid
>memory of that system was typing in the IPL sequence on the 1052.

Shirley 1407. I recall seeing Selectric® typewriters as consoles
before the S/360, but not the 1052.

[Dan Espen]

If they were, then the fill byte occupying a position outside the
ultimate target area was a big mistake.

If you've squeezed your columns together like this:

ZZ,ZZZ.99-ZZ.ZZZ.99-

Then COBOL must edit in a work area.

I think ED and EDMK just have a logical or default design,
equally suited to Asm, PL/I, RPG, COBOL.

C, not so much.


--
Dan Espen

[Anne & Lynn Wheeler]

"Charles Richmond" <nume...@aquaporin4.com> writes:
> Which was a resounding failure. ISTM that the iAPX432 was too
> ambitious for the "state of the art" chip development at the time.

432 architecture book intro references burroughs and system/38 ... part
of intro in this old post:
http://www.garlic.com/~lynn/2000f.html#48 Famous Machines and Software that didn't

'81 acm sigops at asilomar there was presentation by some people from 432
group. besides capability there was lots of complex operating system
dropped into silicon. lots of bugs and every fix required new silicon
chip replacement.

1975 i had done design for 370/125 (never shipped) ... wasn't the 432
capability ... but lots of complex operating system stuff that 432
dropped into (silicon) machine ... i defined as part of "machine" ...
5-way smp, raised level i/o abstract ... but it was all "microcode"
... fixes were floppy disk.

past posts mentioning 432
http://www.garlic.com/~lynn/2000d.html#57 iAPX-432 (was: 36 to 32 bit transition
http://www.garlic.com/~lynn/2000d.html#62 iAPX-432 (was: 36 to 32 bit transition
http://www.garlic.com/~lynn/2001g.html#36 What was object oriented in iAPX432?
http://www.garlic.com/~lynn/2002d.html#27 iAPX432 today?
http://www.garlic.com/~lynn/2002d.html#46 IBM Mainframe at home
http://www.garlic.com/~lynn/2002l.html#19 Computer Architectures
http://www.garlic.com/~lynn/2002o.html#5 Anyone here ever use the iAPX432 ?
http://www.garlic.com/~lynn/2003e.html#54 Reviving Multics
http://www.garlic.com/~lynn/2003m.html#23 Intel iAPX 432
http://www.garlic.com/~lynn/2003m.html#24 Intel iAPX 432
http://www.garlic.com/~lynn/2003m.html#47 Intel 860 and 960, was iAPX 432
http://www.garlic.com/~lynn/2004q.html#64 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2005q.html#31 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006n.html#42 Why is zSeries so CPU poor?
http://www.garlic.com/~lynn/2006p.html#15 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006t.html#7 32 or even 64 registers for x86-64?
http://www.garlic.com/~lynn/2009o.html#13 Microprocessors with Definable MIcrocode
http://www.garlic.com/~lynn/2009o.html#18 Microprocessors with Definable MIcrocode
http://www.garlic.com/~lynn/2010h.html#40 Faster image rotation
http://www.garlic.com/~lynn/2011l.html#2 68000 assembly language programming

--
virtualization experience starting Jan1968, online at home since Mar1970

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <icfw5jz...@home.home>, on 10/12/2012
> at 10:00 AM, Dan Espen <des...@verizon.net> said:
>
>>The last 360 assembler I wrote, was ... well, right now.
>
> 360? I could understand Assembler (XF) if you're using Hercules to
> run, e.g., MVS, but why S/360?

Uh, what am I supposed to do, use IBMs brand of the day terminology?
Yeah, it's a z/10 with z/OS and HLASM.

But to me it's still a S/360 running MVS.

At work, when IBM came up with the z/ terminology, I put my foot down.
No way we were going through every document we had changing MVS to z/OS
only to change again in a few years. It's MVS and it's staying that way
until it really changes.

--
Dan Espen

[Ahem A Rivet's Shot]

On Fri, 12 Oct 2012 11:24:07 -0500
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:

> In <20121012151512.5dfb...@eircom.net>, on 10/12/2012
> at 03:15 PM, Ahem A Rivet's Shot <ste...@eircom.net> said:
>
> >C's stupid null terminated strings are what make highly efficient (in
> >time and memory) things like strtok possible.
>
> How is it more efficient with a null-terminated string than with a
> string that includes a length field? In fact, how is it even equally
> efficient? Consider the code to concatenate two strings.

Some operations are more efficient some are less so. One operation
that is very efficient with null terminated strings is converting a string
of tokens into an array of strings by dropping nulls into the string at the
terminators and recording pointers.

[Rod Speed]

jmfbahciv <See....@aol.com> wrote
> hanc...@bbs.cpcn.com wrote
>> Peter Flass <Peter_Fl...@Yahoo.com> wrote

>>>> The history of programming languages and the history of
>>>> CPU are two separate issues. They developed separately.

>>> They really did develop in tandem. Why was Autocoder the most popular
>>> language on 14xx machines? COBOL was available at the time, why not use
>>> it? One big reason is the time it took to compile a COBOL program, the
>>> system wasn't big or fast enough. Look at IBM's OS/360 compilers - why
>>> did they have multiple versions like FORTRAN D, FORTRAN E, FORTRAN H,
>>> etc.? Because memory was a major restriction and they had to trade-off

>>> features and capability in order to get the compiler to fit. . . .

>> That is all true. Compilers needed more horsepower.

>> But high level languages were independent of CPUs.

> Wrong.

Nope.

> Not at the time the first compilers/interpreters were written.

Fraid so.

> EAch one was written to solve a particular problem for
> the people who were working on a particular machine.

Nope. Have fun listing where that is true for Fortran.

> COBOL is an example.

Nope.

> Even the HLLs which were written as a univerity
> exercise/class was tied to a particular machine.

Plenty of them weren't.

> You can tell (usually) which machine it was
> from the decisions made when implemented.

Have fun doing that with Fortran.

> If a compiler was useful enough, the compiler
> was implemented on more architectures.

And so was independent of the architecture.

> That's when the Standards committed get formed
> to write a functional spec for the entire industry.

Irrelevant to your claim about independence from the architecture.

>> For instance, Fortran was developed by IBM, yet by
>> many others, and used on a variety of machines.

And particularly early on was the only
HLL used much by some industry sectors.

The big rash of HLLs came later.

>> COBOL was developed by an industry trade group. The
>> languages could, if really wanted, run on the smaller
>> machines. (I believe some Fortran programs were
>> "pre screned" on 1401s used as a spooler to the 7090).

> FORTAN II was available on the 1620.

[Elliott Roper]

In article <50784427$30$fuzhry+tra$mr2...@news.patriot.net>, Seymour J.

<spam...@library.lspace.org.invalid> wrote:

> In <20121012151512.5dfb...@eircom.net>, on 10/12/2012
> at 03:15 PM, Ahem A Rivet's Shot <ste...@eircom.net> said:
>
> >C's stupid null terminated strings are what make highly efficient (in
> >time and memory) things like strtok possible.
>
> How is it more efficient with a null-terminated string than with a
> string that includes a length field? In fact, how is it even equally
> efficient? Consider the code to concatenate two strings.

;Inner loop of a .ASCIZ string copy

10$: MOVB (R0)+,(R1)+
BNE 10$

It was a popular meme when unix were but a lad. Code was short and fast
enough.

You could do it faster with longer (counted) strings and more memory
with long blocks of
MOV (R0)+,(R1)+
MOV (R0)+,(R1)+
MOV (R0)+,(R1)+
MOV (R0)+,(R1)+
MOV (R0)+,(R1)+
MOV (R0)+,(R1)+
...
and a bit of messing about at the edges to handle the strings starting
on odd boundaries and the length being other than a multiple of the
block length. There was a neat one of those in the RSX-11M exec.

Then the VAX spoiled all your fun with a MOVC3 instruction. or was it
MOVC5?

I miss pdp-11 assembler. I never could understand all the missionary
zeal over so-called HLLs at the time. With a decent library of macros,
it was usually easy to win against FORTRAN and c in time to develop,
speed of execution and size of executable.

The one area where I lost out was handing my code over to someone else.

--
To de-mung my e-mail address:- fsnospam$elliott$$
PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248

[lawr...@gandi.cluon.com]

"Charles Richmond" <nume...@aquaporin4.com> writes:

> <lawr...@gandi.cluon.com> wrote in message
> news:87391k2...@gandi.cluon.com...
>> "Charles Richmond" <nume...@aquaporin4.com> writes:
>>>>
>>>
>>> I have programmed in C for circa 20 years... and I have yet to even
>>> use a bitfield in a structure. I would wager that the bitfield is
>>> seldom used by most C programmers. I did *once* have the occasion to
>>> use the setjmp/longjmp facility.
>>>
>>
>> I've used it in two places in my life (bitfields, not setjmp/longjmp -
>> which I've also used "about twice" but can't recall exactly where).
>>
>> Both were "embedded"ish applications - one for the Sega Genesis, where
>> we used bitfields just to map the fields in the hardware registers for
>> the video stuff into C structures. This was more than just syntactic
>> sugar, because the code could produce sprite tables at run time on the
>> stack and then call a service routine that would enqueue a DMA for the
>> next vblank interval. (I still have all of the libraries we wrote for
>> that platform, now running under GCC 4.x and occasionally write code to
>> run under an emulated Genesis. $DEITY how I loved that platform.)
>>
>
> By "bitfields" we are talking about a bitfield that exists in a
> structure... *not* just a byte used as an "array" of bits. You'd
> better be careful using bit fields for hardware registers... the exact
> placement of the bitfields is implimentation specific (according to
> the C standard). Use a different C compiler and you could get royally
> screwed!!!
>

Even better, change the optimization settings on the compiler we were
using and it would re-arrange the bits in the structure and suddenly
none of your code would work. BTDT, GTTS.

>
> I worked with a guy at a PPoE on an embedded MC6800 (that's the 8-bit
> processor) code written in assembly. The processor was built by
> Hitachi, who at one point licensed some of the Motorola 8-bit
> processors. The chip had 128 bytes of on-board RAM... and that was
> *all* the RAM used, *no* other RAM chips. One had to be *very*
> careful about subroutine call levels and leaving enough room in the
> stack for an interrupt service to happen, which automatically pushed a
> lot of registers.
>
> --

I bought one of the 6800-series chips with the integrated EPROM for a
project oh-so-long-ago, 68705 - which had "not quite" 128 bytes of RAM
(because the first dozen octets of the RAM space were stolen for the IO)

I used it to to read a little matrix keyboard and drive an LCD text
display on one side and a slow serial port on the other. I had a
specific mission in mind at the time why I wanted a "tiny durable
terminal" and now 15 years later, I can't for the life of me remember
WHY.

[Ahem A Rivet's Shot]

On Fri, 12 Oct 2012 17:50:30 +0100
Elliott Roper <nos...@yrl.co.uk> wrote:

> ;Inner loop of a .ASCIZ string copy
>
> 10$: MOVB (R0)+,(R1)+
> BNE 10$

C source:

while (*t++ = *s++);

Wow that's similar.

[lawr...@gandi.cluon.com]

lawr...@gandi.cluon.com writes:
>
> Even better, change the optimization settings on the compiler we were
> using and it would re-arrange the bits in the structure and suddenly
> none of your code would work. BTDT, GTTS.

It's worth mentioning, since the cross-compiler we were using was sold
targetting exactly that kind of mission, there was a chapter in the
documentation explaining exactly how the mapping of bitfields into the
containing structure would be implemented with various optimization
levels, so you could compel it to pack the bits the way you wanted.

The problem that won me the T-Shirt was a programmer who didn't know
that had changed the makefile for his project and suddenly it stopped
working. He was CERTAIN it was a compiler bug that was generating "bad
code", it never dawned on him that the compiler does more than generate
code.

As I think about it more, that's a good example of a case where
"institutional memory" plays a big role -- all the people who were on
the team during the development of the "animated sprite file to object"
tool-chain knew exactly how it worked, but as a new hire, he was unaware
that the program that read the IFF files (from the art department who
all used Amigas) generated a C file (with no actual CODE, just a bunch
of data initializers) and then compiled that file. Eventually, the
tool-chain grew a little more complex and rather than rely on makefile
rules would fire off a call to the compiler directly.

--NK1G

[Elliott Roper]

In article <PM0004CBD...@ac81381f.ipt.aol.com>, jmfbahciv
<See....@aol.com> wrote:

> Louis Krupp wrote:
> > On Wed, 10 Oct 2012 04:42:04 +0000 (UTC), Rajib Kumar Bandopadhyay
> > <bkpsu...@gmail.com> wrote:
>
> <snip>
>
> Louis--would pointing at _Introduction to Programming_ by Digial's
> Small Computer Handbook Series help? It's very detailed so I usually
> point someone at it who wants to learn how to code, not learn an overview.

Ahh, the brown book on programming the PDP-8 that DEC handed out for
free at trade shows?

It's what got me started. In 1967, straight off the boat from Melbourne
to spend a couple of years bumming round Europe, I took a porter job at
London's Olympia. It was common to accept a bit of drag-out loss as a
tip when you delivered a trolley of booze to each exhibitor's stand.
The pay was rubbish, but you went home feeling pretty merry. I grabbed
an "Introduction to Programming" from the DEC booth one afternoon when
it was getting a bit difficult to walk, and for the rest of the show, I
was getting them to correct my 'homework' by way of tip. They kind of
adopted me. It was ace fun. Three years later I was sort-of pioneering
computer typesetting at Reuters after convincing my boss that it would
be easy on PDP-8's.

I can still dredge up how I felt diving into that book. "Oh Yess!" and
"Natch" and "It's not magic, it just makes sense". Assembler remained
the most fun way to write code for the rest of my working life.

[Elliott Roper]

In article <20121012180325.27c2...@eircom.net>, Ahem A

Rivet's Shot <ste...@eircom.net> wrote:

> On Fri, 12 Oct 2012 17:50:30 +0100
> Elliott Roper <nos...@yrl.co.uk> wrote:
>
> > ;Inner loop of a .ASCIZ string copy
> >
> > 10$: MOVB (R0)+,(R1)+
> > BNE 10$
>
> C source:
>
> while (*t++ = *s++);
>
> Wow that's similar.

It does suggest that c was influenced by the pdp-11 instruction set at
an early age. It also illustrates how even LL HLL's obfuscate the
bleedin' obvious.

[Charles Richmond]

<lawr...@gandi.cluon.com> wrote in message
news:87bog7z...@gandi.cluon.com...
>
> [snip...] [snip...]
> [snip...]

>
> I bought one of the 6800-series chips with the integrated EPROM for a
> project oh-so-long-ago, 68705 - which had "not quite" 128 bytes of RAM
> (because the first dozen octets of the RAM space were stolen for the IO)
>
> I used it to to read a little matrix keyboard and drive an LCD text
> display on one side and a slow serial port on the other. I had a
> specific mission in mind at the time why I wanted a "tiny durable
> terminal" and now 15 years later, I can't for the life of me remember
> WHY.
>

Back in university, when all the professors tried to pound into us about
writing documentation and commenting code, we did *not* understand...
because we *could* remember what the code did. Now that we are older (like
the professors were), we *understand* why we need to write stuff down....
because "15 years later, I can't for the life of me remember WHY." :-)

-

[Scott Lurndal]

The burroughs medium systems instruction set was designed _specifically_ for
COBOL.

E.g. the burroughs edit instruction:

http://vseries.lurndal.org/doku.php?id=instructions:edt

Searching:

http://vseries.lurndal.org/doku.php?id=instructions:sea

Even the memory architecture (addressed to the digit/nibble) and operand
structure (100 digit or 100 byte operands, with zone digits added automatically
by the hardware) was designed around COBOL (and compatiability with the B300).

scott

[Charlie Gibbs]

In article <1d1b5bea-99f0-493c...@googlegroups.com>,
bkpsu...@gmail.com (bkpsusmitaa) writes:

> On Thursday, 11 October 2012 03:19:33 UTC+5:30, Seymour J. Shmuel Metz
> wrote:
>
>> I suspect that demerit is the word he meant.
>
> Precisely, newer systems are developed to overcome the difficulties
> with the present systems.

And the system after that is developed to overcome the warts
introduced in the "newer" version.

"Change is inevitable. Progress is not."

> Please, let us stop this thread and continue with our discussion
> on the history part.

But thread drift is a sacred tradition on this group. :-)

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

[Rich Alderson]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <k58f1c$m13$1...@dont-email.me>, on 10/12/2012
> at 06:57 AM, Rajib Kumar Bandopadhyay <bkpsu...@gmail.com> said:

>> Does that mean PL/I can still be used in place of C? That is
>> supposed to be anachronistic?!

> A Trabant is a newer car than a Rolls Royce Silver Cloud. PL/I is a
> much better language than C, just harder to implement on a PDP-7.

I'm not sure that C would be much easier to implement on the PDP-7. It has an
awful lot of assumptions of byte-structured memory built in.

If you're thinking about the PDP-7 as the original platform for Unics => Unix,
that was all assembler, as was the port to the PDP-11. Research Version 1 of
Unix, the first one done in C, is the third version done on the PDP-11...

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

[Rich Alderson]

jmfbahciv <See....@aol.com> writes:

> hanc...@bbs.cpcn.com wrote:

>> But high level languages were independent of CPUs.

> Wrong. Not at the time the first compilers/interpreters were written.

> EAch one was written to solve a particular problem for the people

> who were working on a particular machine. COBOL is an example.

> Even the HLLs which were written as a univerity exercise/class was

> tied to a particular machine. You can tell (usually) which machine

> it was from the decisions made when implemented.

Barb, I'm sorry to say this, but you're wrong about this.

I've just been working on one of those hideous^Wexciting posters supposed to
show the general public the history of programming languages. I've been
reading original documents, early histories, and the like. There were
languages intended for business processing prior to COBOL, including one known
as B-0 ("Business language 0")--later FLOW-MATIC--which was created by one
Grace Hopper; it informed but did not dominate the design done by committee
which was christened COBOL.

You said "Even..." when talking about univeristy research languages, where you
should have said "Of course..." No one in that context would write for a
machine to which they had no access.

FORTRAN was created for the IBM 704, and it shows in some of the archaic parts
of the language (which may have all been dropped in the latest standard, it's
been years since I worried about Fortran). The most modern Lisp dialects still
show their 704/7094 heritage (car and cdr), but only to those who have studied
the history.

But there were efforts from the earliest days to standardize languages, often
prior to one word of code coming into existence.

[Rich Alderson]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <k57m14$dqv$1...@dont-email.me>, on 10/11/2012
> at 07:57 PM, Peter Flass <Peter...@Yahoo.com> said:

>> iAPX432.

> That was a capability-based architecture. It was certainly high level,
> but I don't know of anything in it to support a specific language.

Intel's marketing literature positioned it as a very good candidate for Ada.

[Bill Findlay]

On 12/10/2012 22:45, in article mddd30n...@panix5.panix.com, "Rich

Alderson" <ne...@alderson.users.panix.com> wrote:

> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
>
>> In <k57m14$dqv$1...@dont-email.me>, on 10/11/2012
>> at 07:57 PM, Peter Flass <Peter...@Yahoo.com> said:
>
>>> iAPX432.
>
>> That was a capability-based architecture. It was certainly high level,
>> but I don't know of anything in it to support a specific language.
>
> Intel's marketing literature positioned it as a very good candidate for Ada.

They were economical with the actualit�.

--
Bill Findlay
with blueyonder.co.uk;
use surname & forename;