>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.
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?
> On 10/11/2012 9:11 AM, Walter Bushell wrote:
> > 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?
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.
In article <k57m14$dq...@dont-email.me>,
Peter Flass <Peter_Fl...@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.
Bob Martin <bob.mar...@excite.com> writes:
> in 580242 20121012 091309 Nick Spalding <spald...@iol.ie> wrote:
>>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.
The last 360 assembler I wrote, was ... well, right now.
Just did a make, waiting for the compile/test results.
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.
hanco...@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).
Louis Krupp wrote:
> On Wed, 10 Oct 2012 04:42:04 +0000 (UTC), Rajib Kumar Bandopadhyay
> <bkpsusmi...@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.
Bob Martin wrote:
> in 580242 20121012 091309 Nick Spalding <spald...@iol.ie> wrote:
>>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.
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 ;-)
> in 580241 20121012 090435 Nick Spalding <spald...@iol.ie> wrote:
> >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.
> 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
>>> 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. :-)
Peter Flass <Peter_Fl...@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/
>>>> 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.
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?
In <k58vr0$hl...@dont-email.me>, on 10/12/2012
at 07:51 AM, Peter Flass <Peter_Fl...@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.
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
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
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
>> 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.
>> 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.
> 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.
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.
>> 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.
> 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.
