Peter Flass wrote:
> 
> Hey!  C's finally caught up to PL/I.  Only took them 50 years, and then
> of course all the features are just tacked-on in true C fashion, instead
> of thought-through.

Well, that's rather insulting to the members of WG14, who spent a
decade designing those features. Fortunately, they published the
Rationale showing that, in fact, they were thought through.[1] And a
great deal of documentation describing the process is available in the
archives.[2]

If you'd care to show why you think otherwise, perhaps there would be
some grounds for debate.


[1] www/C99RationaleV5.10.pdf" target=_blank rel="nofollow">http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
[2] www/documents.html" target=_blank rel="nofollow">http://www.open-std.org/JTC1/SC22/WG14/www/documents.html

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

On Tue, 02 Mar 2010 13:24:00 -0500
Michael Wojcik <m...@newsguy.com> wrote:

> Ahem A Rivet's Shot wrote:
> > On Fri, 26 Feb 2010 13:48:48 -0500
> > Michael Wojcik <m...@newsguy.com> wrote:
> > 
> >> Ahem A Rivet's Shot wrote:
> >>> 	No, he's saying that C doesn't really implement an array type,
> >>> the var[offset] syntax is just syntactic sugar for *(var + offset)
> >>> which is why things like 3[x] work the same as x[3] in C.
> >> That's not quite correct. C does implement an array type (or, rather,
> >> an array type qualifier which can be used to implement arrays of any
> >> object type); it's just not first-class.
> > 
> > 	This is saying the same thing as I did in different terms and
> > with greater detail.
> 
> I supposed, if you want to gloss "doesn't really implement an array
> type" as "does implement an array type". That seems rather a stretch
> to me.

	That "first-class" bit is the "really".

-- 
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/

Joe Pfeiffer wrote:
> "(see below)" <y...@blueyonder.co.uk> writes:
> 
>> On 24/02/2010 23:55, in article
>> 1...@snowball.wb.pfeifferfamily.net, "Joe Pfeiffer"
>> <p...@cs.nmsu.edu> wrote:
>>
>>> When I was an undergrad I spent some time programming FORTRAN on a
>>> Harris /6 (I think it was a /6 -- there's something nagging at the back
>>> of my mind that says it may have been a /7).  Anyway, reading the manual
>>> I discovered that return addresses were stacked, and immediately jumped to
>>> the conclusion that it could do recursion.  It turned out that local
>>> variables were static...  which meant I spent a *long* time figuring out
>>> why my program was producing completely nonsensical results.
>>>
>>> As Al Stewart once sang, "I was jumping to conclusions, and one of them
>>> jumped back."
>> People who assumed that FORTRAN local variables *must* be static got jumped
>> on from the opposite direction when they used FORTRAN compilers that
>> actually did put them on the stack, as the ANS FORTRAN standard was
>> carefully worded to permit.
> 
> All these decades I thought that was the case....  of course, I only
> programmed FORTRAN for a couple of years around 1980.

With the older FORTRAN's, you have to "know your implementation". 
Tricks were used especially to handle ASCII data in numeric 
variables in the early days.

-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

Michael Wojcik wrote:
> Peter Flass wrote:
>> Hey!  C's finally caught up to PL/I.  Only took them 50 years, and then
>> of course all the features are just tacked-on in true C fashion, instead
>> of thought-through.
> 
> Well, that's rather insulting to the members of WG14, who spent a
> decade designing those features. Fortunately, they published the
> Rationale showing that, in fact, they were thought through.[1] And a
> great deal of documentation describing the process is available in the
> archives.[2]
> 
> If you'd care to show why you think otherwise, perhaps there would be
> some grounds for debate.

"The flexible array must be last"?

"sizeof applied to the structure ignores the array but counts any 
padding before it"?

C is a collection of ad-hoc ideas.  WG14 may have put a great deal of 
thought into how to extend it without breaking the existing mosh, but 
that's my point, it's still a mosh.

On Mar 2, 5:38=A0pm, Charles Richmond
<friz...@tx.rr.com> wrote:
> Joe Pfeiffer wrote:
> > "(see below)" <yaldni...@blueyonder.co.uk> writes:
>
> >> On 24/02/2010 23:55, in article
> >> 1bmxyy42ag....@snowball.wb.pfeifferfamily.net, "Joe Pfeiffer"
> >> <pfeif...@cs.nmsu.edu> wrote:
>
> >>> When I was an undergrad I spent some time programming FORTRAN on a
> >>> Harris /6 (I think it was a /6 -- there's something nagging at the ba=
ck
> >>> of my mind that says it may have been a /7). =A0Anyway, reading the m=
anual
> >>> I discovered that return addresses were stacked, and immediately jump=
ed to
> >>> the conclusion that it could do recursion. =A0It turned out that loca=
l
> >>> variables were static... =A0which meant I spent a *long* time figurin=
g out
> >>> why my program was producing completely nonsensical results.
>
> >>> As Al Stewart once sang, "I was jumping to conclusions, and one of
th=
em
> >>> jumped back."
> >> People who assumed that FORTRAN local variables *must* be static got j=
umped
> >> on from the opposite direction when they used FORTRAN compilers that
> >> actually did put them on the stack, as the ANS FORTRAN standard was
> >> carefully worded to permit.
>
> > All these decades I thought that was the case.... =A0of course, I only
> > programmed FORTRAN for a couple of years around 1980.
>
> With the older FORTRAN's, you have to "know your implementation".
> Tricks were used especially to handle ASCII data in numeric
> variables in the early days.
>

In really older FORTRANs, you would more likely know the tricks used
to
handle BCDIC or SIXBIT character data as numeric variables.

Bruce B. Reynolds, Trailing Edge Technologies, Warminster PA

Peter Flass <P...@Yahoo.com> writes:

> Michael Wojcik wrote:
>> Peter Flass wrote:
>>> Hey!  C's finally caught up to PL/I.  Only took them 50 years, and then
>>> of course all the features are just tacked-on in true C fashion, instead
>>> of thought-through.
>>
>> Well, that's rather insulting to the members of WG14, who spent a
>> decade designing those features. Fortunately, they published the
>> Rationale showing that, in fact, they were thought through.[1] And a
>> great deal of documentation describing the process is available in the
>> archives.[2]
>>
>> If you'd care to show why you think otherwise, perhaps there would be
>> some grounds for debate.
>
> "The flexible array must be last"?
>
> "sizeof applied to the structure ignores the array but counts any
> padding before it"?
>
> C is a collection of ad-hoc ideas.  WG14 may have put a great deal of
> thought into how to extend it without breaking the existing mosh, but
> that's my point, it's still a mosh.

iostream formatting operators, because we really need more operator
overloading and no enhancements are too bizarre in service of making
everything, (for particular values of everything), specialized?

Oh but wait, you can compile, install and dig your way through Boost so
as to avoid the fun & games of vanilla iostream.

Thank goodness printf and friends are still around.

Which I suppose isn't an argument that the feature wasn't designed, but
is perhaps in support of the "ad-hoc" argument.  One more wacky idea
thrown on the pile for the amusement of the programmer.

Gregm

On Feb 8, 12:46=A0am, Mike Hore
<mike_hore...@OVE.invalid.aapt.net.au>
wrote:
> (see below) wrote:
> > On 05/02/2010 18:19, in article
> > badc12c3-cb2b-4ce9-9543-237d60fc2...@o8g2000vbm.googlegroups.com, "Eric
> > Chomko" <pne.cho...@comcast.net> wrote:
>
> >> Has anyone created a copy machine of an old system using an FPGA? I
> >> was wondering if it would be possible to take an entire SWTPC 6800 and
> >> compile the schematics and have it run on an FPGA board.? Wouldn't
> >> even have to be the latest Xylinx product, I suspect.
>
> > I think such a project would valuable, and perhaps even more valuable i=
f it
> > aimed to recreate a machine of the "heroic" era -- a 7094, an Atlas,
or=
 a
> > KDF9, say. Perhaps even a Stretch.
>
> A KDF9, maybe, but Stretch? =A0You'd have to be seriously masochistic, or
> downright insane =A0:-)

I keep hoping for an FPGA that would be suitable for replicating the
internal logic of an IBM 360/195, as an example, so that if I did
build a replica of a computer, I could have a reasonably efficient
implementation which would give performance at least roughly in the
ballpark of a Pentium - at least an early one.

I'm working on refining the ISA for my own example computer design -
based on the parsimonious use of opcode space made possible by the old
SEL 32 trick used in Aligned Operand Mode, I think I can indeed
abandon the multitudinous alternative instruction modes, and not only
have just one - but have one with the property that a minimal number
of logic gates are required to determine the number of 16-bit
halfwords which constitute any given instruction.

On Mar 3, 7:06=A0pm, Greg Menke
<guse...@comcast.net> wrote:
> Peter Flass <Peter_Fl...@Yahoo.com> writes:
> > Michael Wojcik wrote:
> >> Peter Flass wrote:
> >>> Hey! =A0C's finally caught up to PL/I. =A0Only took them 50 years, an=
d then
> >>> of course all the features are just tacked-on in true C fashion, inst=
ead
> >>> of thought-through.
>
> >> Well, that's rather insulting to the members of WG14, who spent a
> >> decade designing those features. Fortunately, they published the
> >> Rationale showing that, in fact, they were thought through.[1] And a
> >> great deal of documentation describing the process is available in the
> >> archives.[2]
>
> >> If you'd care to show why you think otherwise, perhaps there would be
> >> some grounds for debate.
>
> > "The flexible array must be last"?
>
> > "sizeof applied to the structure ignores the array but counts any
> > padding before it"?
>
> > C is a collection of ad-hoc ideas. =A0WG14 may have put a great deal of
> > thought into how to extend it without breaking the existing mosh, but
> > that's my point, it's still a mosh.
>
> iostream formatting operators, because we really need more operator
> overloading and no enhancements are too bizarre in service of making
> everything, (for particular values of everything), specialized?
>
> Oh but wait, you can compile, install and dig your way through Boost so
> as to avoid the fun & games of vanilla iostream.
>
> Thank goodness printf and friends are still around.

More generally when speaking about C++, than goodness C is still
around.

>
> Which I suppose isn't an argument that the feature wasn't designed, but
> is perhaps in support of the "ad-hoc" argument. =A0One more wacky idea
> thrown on the pile for the amusement of the programmer.
>
> Gregm

Eric Chomko <p...@comcast.net>
writes:

>More generally when speaking about C++, than goodness C is still
>around.

One can actually write very maintainable and quite performant applications
in C++ by restricting the subset of C++ the version 2.1 flavor (no STL,
no Templates, no Exceptions, no run-time typing).   Basically C with classes.

One can still use printf, snprintf, setjmp/longjmp etc, while reaping the
data hiding and inheritance/interface benefits of C++.

I've worked on three different operating systems or hypervisors written in
such a restricted dialect.

And yes, I think the iostream stuff is a useless abominable hack.

scott

In comp.arch.fpga Quadibloc
<j...@ecn.ab.ca> wrote:
(snip)
 
> I keep hoping for an FPGA that would be suitable for replicating the
> internal logic of an IBM 360/195, as an example, so that if I did
> build a replica of a computer, I could have a reasonably efficient
> implementation which would give performance at least roughly in the
> ballpark of a Pentium - at least an early one.

Does anyone know if the information needed to do that still exists?

I would go for the 360/91, just a little be easier.

-- glen