pre-requestie for learning C...

[CBFalconer]

It would help if you used a more standard markup, preceding each
line with a marker. "> " is traditional for material quoted
from a previous article. For quotations from another source, I
generally either indent or use a different marker, such as "| ".
(And non-Python programmers might not recognize the convention
you're using of """ on a line by itself.)

I certainly didn't.

 

[Ahem A Rivet's Shot]

I don't see what's not sensible about synthesising bit-oriented
operations using bitwise loops in a language which doesn't support
such things natively.

It seems far from sensible when the underlying hardware almost
invariably has direct single instruction support for XOR.

The problem is that "sensible" is in the eye of the beholder.
It's clear to me that he didn't consider needing a function to
perform the task to be intrinsically non-sensible, otherwise he
would, or should, have ended his argument with a conclusion
immediately after "In particular, there are no bit-manipulation
operators (AND, OR, XOR, etc.)".

A reasonable continuation, but it was the lack of XOR that caused
problems to the case in hand.

 

[Phil Carmody]

It seems far from sensible when the underlying hardware almost
invariably has direct single instruction support for XOR.

That depends if you think that sense in a computer language
only stems from modelling the underlying architecture for
one or many machines. Most computer languages aren't designed
that way - most are high level.

For example, languages with explicit vector (altivec/MMX/VFP/
etc.) types and operations are few and far between, despite
the relative commonness of them in modern processor archs.
Does ``for(int i=0; i<4; ++i) { c=a*b; }'' make C or C++
not ones favourite language as there's no "sensible" way of
doing the same thing atomically? Does this make Dan Bernstein's
QHASM the only sensible language?

Phil

 

[Ahem A Rivet's Shot]

That depends if you think that sense in a computer language
only stems from modelling the underlying architecture for
one or many machines. Most computer languages aren't designed
that way - most are high level.

Well I don't think it's sensible to require a high level loop for
an operation that is *commonly* implemented in hardware and has been for
about as long as there have been CPUs. Are there any binary CPUs that don't
provide a bitwise XOR in hardware ?

I don't consider this the only criterion for sensible, but it is
one, but the criticism wasn't that the language wasn't sensible, but that
there was no way to write a sensible XOR function.

For example, languages with explicit vector (altivec/MMX/VFP/
etc.) types and operations are few and far between, despite
the relative commonness of them in modern processor archs.
Does ``for(int i=0; i<4; ++i) { c=a*b; }'' make C or C++
not ones favourite language as there's no "sensible" way of
doing the same thing atomically?

If I was planning on making heavy use of vector operations then not
being able to express them in such a way that the compiler could make use
of the available processor capabilities would indeed be a disadvantage. So
yes I would regard this as a weakness of C, partially offset by the ease of
adding functions implemented in assembler.

Does this make Dan Bernstein's QHASM the only sensible language?

ISTR APL providing vector operations as primitives, also some
BASICs have matrix arithmetic - there are probably many others.

 

[Richard Bos]

You (and WPINMFPL's author) are unfair.

There is a C standard, and if follow it strictly, C is a language as
useless as Pascal. The proof is in all the kernels, where
non-standard extensions to the standard C language have to be used to
actually work.

That sounds like you're confusing the C core language with the complete
C Standard, which includes the library as well as the grammar. And
that's quite a bit more useful than the complete Pascal language.

The same is true with Pascal. Implementation on systems other than
punch-card/line-printer/batch computers include extensions

Precisely. But the language standard doesn't provide a way to, for
example, read and write binary files.

Hey! Stop the bullshit about Pascal,

I have both a Pascal Standard (granted, an early one) and a C Standard
(both the one you probably know and the current version). Which do you
have?

Richard

 

[Richard Bos]

I have no opinions on that,

You should.

I suggest you express the problems in a manner understandable to all

I did.

Richard

 

[Richard Bos]

Yes, sorry. I see it now. I just copied from the previous
message, without paying strict attention.

And Her Majesty Anne of England, Scotland and Ireland has passed away.

Richard

 

[Richard Bos]

I'm not a python programmer, '"""' has nothing to do with python,
it's just an arbitrary string which won't by default be interpreted
as text, but as markup. Was the meaning of it unclear to you? Did
you not realise it was a block quote?

The meaning is perfectly clear to a human reader in your post itself,
but it is liable to get lost either by oversight or by programmatical
accident in follow-ups, because it is not at all clear to newsreaders.
Don't blame us if you make it easier for your posts to get misquoted.

Richard

 

[Pascal J. Bourguignon]

That sounds like you're confusing the C core language with the complete
C Standard, which includes the library as well as the grammar. And
that's quite a bit more useful than the complete Pascal language.

We may agree that the area standardized in some given C standard is
bigger than the area standardized in some given Pascal standard.


So we'll have to discuss the usefulness of having big standards
vs. small standards for core language & libraries.


But I still think it's unfair to compare languages on their standard.
We should foremost compare them on their implementations.

Precisely. But the language standard doesn't provide a way to, for
example, read and write binary files.

Yes. And the C standard doesn't provide a way to set a write barrier,
or to set the processor ring, which would be fatal for a kernel
programming language.

However in both cases, Pascal implementations provide ways to read and
write binary files, and C implementations provide ways to implement
low level kernel stuff.

I have both a Pascal Standard (granted, an early one) and a C Standard
(both the one you probably know and the current version). Which do you
have?

I don't have them at hand anymore, I'm working from memory. ;-)

 

[jameskuyper]

Pascal J. Bourguignon wrote:
....

But I still think it's unfair to compare languages on their standard.
We should foremost compare them on their implementations.

Is a language itself bad just because no one has yet created a good
implementation for it (or vice versa)?

Is it fair to compare a great implementation of C with a lousy
implementation of Pascal (or vice versa)? If you do both comparisons,
and they give opposite results, what reasonable conclusions can you
reach about which language (as opposed to implementation) is best?

 

[luser-ex-troll]

This is directed to all participants, en masse.
As an attempt to redirect the discussion back towards
the original topic, I make the following assertions.

Brian Kernighan likes C better than Pascal for systems programming.
And for any computer implemented on binary
hardware (this excludes Babbage's Difference Engine
and Analytical Engine, and the Royal Aircraft
Establishment Sequence-Controlled Calculator and
anything with dekatrons in it), xor is a basic operation
(hardware instruction). High-level gyrations of the
sort exhibited by the respectable Pascal implementation
posted earlier in this thread are unappealing to Brian
Kernighan, for good reason.

Turbo Pascal offered many useful extensions but failed
to fully implement the standard. It is more appealing
for beginning programming than, say, GWBASIC for DOS4.0.

If someone wants to learn programming and intends to
make a heavy investment in a single language, C is
an acceptable choice due to its ubiquity, demonstrated
capability, and unlimited flexibility. If desired,
C can be used to implement a mini-language offering
much of its power in a more friendly environment.
Or one may select such a mini-language as a stepping-
stone toward C. Or away from it.

C may not be a good choice if one is unwilling to
undergo a lengthy period of "initiation."

Flame on!

lxt
PS. Chuck, do you have any extra DAC-512s? They look
really cool. Like something from the bridge of Star Trek!

 

[Phil Carmody]

The meaning is perfectly clear to a human reader in your post itself,
but it is liable to get lost either by oversight or by programmatical
accident in follow-ups, because it is not at all clear to newsreaders.
Don't blame us if you make it easier for your posts to get misquoted.

My assertion would be that I didn't. Chuck removed important context
that by default would have been preserved by any sane newsreader.
Not really different from over-trimming attribution lines, which is
oft seen. It's the human that does that additional cutting.

Phil

 

[JosephKK]

You can leave out a couple of exclamation marks:
#define LOGICAL_XOR(a,b) (!(a) != !(b))

Maybe. !! causes an implicit type conversion.
.

 

[JosephKK]

No it is not. Simply because like with C, you don't use a standard
language, you always use a specific implementation, and in specific
implementations, you are provided with all the practical features
omited by the standard.

Really? I did not hear that USDoD allowed non-conformant
implementations of Ada. (well at least for their software
deliverables)

 

[Nate Eldredge]

I had to go check against my memory and i verified that 6502 does not
have atomic bitwise XOR. See:

http://www.atarimax.com/jindroush.atari.org/aopc.html#TOC

You are right, and wrong. They called it EOR.

http://www.atarimax.com/jindroush.atari.org/aopc.html#EOR

I think whoever wrote their assembler had spent too much time in a
Gloomy Place eating Thistles.

 

[Sjouke Burry]

I had to go check against my memory and i verified that 6502 does not
have atomic bitwise XOR. See:

Tsssk...Checking my BBC Electron manual:
It contains the 6502 processor.
And it has the EOR instruction, it does have XOR(on 8 bit data).

 

[JosephKK]

Phil Carmody said:

Nor does anything else.

 

[Phil Carmody]

Phil Carmody said:



It doesn't easily survive aggressive quote-n-snip.

I posit the problem is the aggressive nature of the snipping.

On the other hand: "Use of a line prefix rather than a block prefix
would have required on my part the insertion of characters to every
line, and the possible re-wrapping of text such that less-capable
clients when replying do not leave partial lines without the line
prefix", as Phil Carmody once said.

Did you not notice that I was quoting several paragraphs, including
material where whitespace and indenting were important? I'm perfectly
capable of using in-line quotes where appropriate, the situation at
hand was not such a case.

Phil

 

[Guest]

I believe there are other sorts of program besides kernels.

We may agree that the area standardized in some given C standard is
bigger than the area standardized in some given Pascal standard.
ok

So  we'll have  to  discuss  the usefulness  of  having big  standards
vs. small standards for core language & libraries.

I hardly think the C standard qualifies as "big"

But I still think it's unfair to compare languages on their standard.
We should foremost compare them on their implementations.

As the direct descendent of lawyers I learned to spot rhetorical
devices
like this before I could walk. You are moving the goalposts. The
debate
*is* about the implementation of the standard. And Turbo Pascal failed
to be an implementaion of the standard (though, a very fun language
nevertheless).

Yes.  And the C standard doesn't provide a way to set a write barrier,
or to set the processor ring, which would be fatal for a kernel
programming language.

Standard C is more widely applicable than Standard Pascal

However in both cases, Pascal implementations provide ways to read and
write binary files, and C implementations provide ways to implement
low level kernel stuff.


I don't have them at hand anymore, I'm working from memory. ;-)

I don't think I actually had a copy of the Pascal Standard. But I did
have
a book that discussed it.

 

[Pascal J. Bourguignon]

I believe there are other sorts of program besides kernels.

Yes. But for any other sort of program other than unix kernel,
C should not be used. And even, for kernel, I'd feel safer if it was
written in Modula-2 or Modula-3 than in C...

I hardly think the C standard qualifies as "big"

Did I say so?

As the direct descendent of lawyers I learned to spot rhetorical
devices
like this before I could walk. You are moving the goalposts. The
debate
*is* about the implementation of the standard. And Turbo Pascal failed
to be an implementaion of the standard (though, a very fun language
nevertheless).
Ok.



Standard C is more widely applicable than Standard Pascal

Yes. But it doesn't matter. because you don't program with standards,
but with actual implementations and extensions.

The consequence may be that it's harder to port Pascal programs than C
programs, because in a Pascal program you may have to use more
implementation specific extensions.

In my experience, it wasn't true. I've used at least three different
Pascal compilers on MacOS, and had no difficulty in porting programs
from one to the other. At least, not more difficulties than when
porting C programs.

I don't think I actually had a copy of the Pascal Standard. But I
did have a book that discussed it.

Once upon a time I knew it by heart