> >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.
"Charles Richmond" <numer...@aquaporin4.com> writes:
> "Ahem A Rivet's Shot" <ste...@eircom.net> wrote in message
> news:20121011133209.cb79a8ed1e62a19511a21b01@eircom.net...
>> On Thu, 11 Oct 2012 07:43:00 -0400
>> Peter Flass <Peter_Fl...@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.
"Charles Richmond" <numer...@aquaporin4.com> wrote:
> "Ahem A Rivet's Shot" <ste...@eircom.net> wrote in message > news:20121011133209.cb79a8ed1e62a19511a21b01@eircom.net...
> > On Thu, 11 Oct 2012 07:43:00 -0400
> > Peter Flass <Peter_Fl...@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.
-- 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/
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 -
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?
> 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.
"Charles Richmond" <numer...@aquaporin4.com> writes:
> "Walter Bushell" <pr...@panix.com> wrote in message > news:proto-E473C6.09111111102012@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 n...@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...
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 spamt...@library.lspace.org
> In article
> <02a8129c-3910-4dc0-acc6-8d1024921...@e18g2000yqo.googlegroups.com>,
> hanco...@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.
I believe there was one, or are you just asking him to think about what it involved?
> "Walter Bushell" <pr...@panix.com> wrote in message
> news:proto-E473C6.09111111102012@news.panix.com...
>> In article
>> <02a8129c-3910-4dc0-acc6-8d1024921...@e18g2000yqo.googlegroups.com>,
>> hanco...@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.
> There *is* a C compiler for the PDP-10/DEC-20. It used 9-bit bytes.
Likewise there's a Multics C compiler for Honeywell DPS-68 machines, though I don't know the details.
>>> 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.
> 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.
Peter Flass <Peter_Fl...@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?
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.
> 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.
The 1401 is a good choice to start. As you mentioned, there is a
simulator available. The 1401 has a basic instruction.
"Peter Flass" 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 -
>> 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.
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).
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.
<bkpsusmi...@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.
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.
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?!
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.
hanco...@bbs.cpcn.com wrote, in
<f77db771-9d68-4de2-925f-0e56cd2e8...@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.
-- Nick Spalding
hanco...@bbs.cpcn.com wrote, in
<d3f91df1-d8b7-4bee-8f53-ccc068c4f...@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.
-- Nick Spalding
On 10/11/2012 9:25 PM, hanco...@bbs.cpcn.com wrote:
> 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.
On 10/12/2012 2:57 AM, Rajib Kumar Bandopadhyay wrote:
> 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?!
"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.
>hanco...@bbs.cpcn.com wrote, in
><d3f91df1-d8b7-4bee-8f53-ccc068c4f...@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.
