Making Fatal Hidden Assumptions

[RSoIsCaIrLiIoA]

How do you get access [from C] to the [hardware's] condition bits?

With the usual gay abandon about extensions, you might define a
variable in system space, say _ccd, to hold those bits. You
specify the conditions under which it is valid, such as immediately
after an expression with precisely two operands, preserved by use
of the comma operator. Then:

a = b + c, ccd = _ccd;

allows you to detect overflow and other evil things.

This turns out not to work very well in Real Compilers. The reasons
are outlined rather nicely in the GCC documentation:

It is a natural idea to look for a way to give access to the condition
code left by the assembler instruction. However, when we attempted to
implement this, we found no way to make it work reliably. The problem
is that output operands might need reloading, which would result in
additional following "store" instructions. On most machines, these
instructions would alter the condition code before there was time to
test it. This problem doesn't arise for ordinary "test" and "compare"
instructions because they don't have any output operands.

For reasons similar to those described above, it is not possible to
give an assembler instruction access to the condition code left by
previous instructions.

(from <http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Extended-Asm.html>).

(You *can* actually capture the condition codes, by doing the
operation itself *and* the condition-code-capture all in one
single inline __asm__, so that no reloading occurs between the
two parts. Getting it right is still fairly tricky. In many
cases you are better off just writing the desired routines in
assembly, and calling them as ordinary functions from the C code.)

in what i understand (if i understand) the solution for all your
problems is to have in the compiler implementation some debug mode for
its exe output: the executable when run opens many queues of 20 items:
one register all overflow
one all memory leak
one all memory wrote out of bound
....
then at end of program all those queue are print in a log file

if after 10 years of use that program has not problem in its
log then it could be compiled without debug queues

 

[Richard Bos]

One can make a case that in at least one aspect, C is _less_ like
assembler than many other high-level languages: for. Most languages only
support for loops looking like FOR n=1 TO 13 STEP 2: NEXT or for n:=10
downto 1 do. Such loops are often easily caught in one, or a few, simple
machine instructions. Now try the same with for (node=root; node;
node=node->next) or for (i=1, j=10; x && y[j]; i++, j--).

True, but
for( <p1>; <p2>; p3> )
looks like a MACRO to me.

*Shrug* If you go about redefining terms to support your delusion that C
is a portable assembler, that's your problem, not that of C.

Richard

 

[Dik T. Winter]

>
> Sorry I don't have access to our archives at the moment -
> we do have materials from 70x and 650 Fortran; to
> which machine are you referring? 704, 709, 650?

The FREQUENCY statement from Fortran I (amongst others on the 704).

 

[Alf P. Steinbach]

* Richard Bos -> someone:

*Shrug* If you go about redefining terms to support your delusion that C
is a portable assembler, that's your problem, not that of C.

Happily I haven't followed this debate, so I don't know what you folks,
good or not, think "portable assembler" means, nor how you can think a
language is a compiler (or whatever).

C was designed as a portable assembly language, the most successful so
far, so if the term has any practical meaning, then C is that meaning.

C was designed as a portable assembly language for the purpose of
porting Unix (which then had some seven or ten installations, I forget,
but one rumor has it there was only one, namely the PDP-7) more easily.
That didn't fully remove the need for using actual assembly. But only
some small parts still needed to be machine-specific assembly.

You can find more information about the C language at e.g. Wikipedia,
<url: http://en.wikipedia.org/wiki/C_programming_language>.

Hth.

 

[RSoIsCaIrLiIoA]

:
How do you get access [from C] to the [hardware's] condition bits?

With the usual gay abandon about extensions, you might define a
variable in system space, say _ccd, to hold those bits. You
specify the conditions under which it is valid, such as immediately
after an expression with precisely two operands, preserved by use
of the comma operator. Then:

a = b + c, ccd = _ccd;

allows you to detect overflow and other evil things.

This turns out not to work very well in Real Compilers. The reasons
are outlined rather nicely in the GCC documentation:

in what i understand (if i understand) the solution for all your
problems is to have in the compiler implementation some debug mode for
its exe output: the executable when run opens many queues of 20 items:
one register all overflow
one all memory leak
one all memory wrote out of bound
...
then at end of program all those queue are print in a log file

if after 10 years of use that program has not problem in its
log then it could be compiled without debug queues

is there someone out there that read this?
am i plonked from all NGs?

 

[Richard Heathfield]

Alf P. Steinbach said:

You can find more information about the C language at e.g. Wikipedia,
<url: http://en.wikipedia.org/wiki/C_programming_language>.

You would do better to visit <http://www.lysator.liu.se/c/> which has a
number of good links to well-established pages about C. The Wiki page
suffers from being modifiable by the clueless.

 

[Chris Dollin]

C was designed as a portable assembly language, the most successful so
far, so if the term has any practical meaning, then C is that meaning.

I would have said it was designed as a portable language to /replace/
[the use of] assembly language(s) [for a variety of "systems programming"
uses].

C looks nothing like any assembly language I've ever seen, which I
suppose may just indicate my limited knowledge of assemblers. Calling
it "portable assembly language" is an instructive metaphor, but it
is just that - a metaphor.

Here are some ways in which C isn't like the assembly languages I've
seen:

* you don't get/need to pick which instructions get used
* you don't get/need to pick the order the instructions are in
* you don't get/need to pick the addressing modes that are used
* you don't have [complete] control over what goes into registers
* you get scoped variables
* you get typed variables [yes, some assemblers handle that]
* "basic" statements don't correspond to single instructions
* use of explicit control structures (if-then, while-do, etc)
is the norm, rather than conditional goto's
* the compiler does mandated useful consistency checking
* compilers and other tools often do additional consistency checking
* a well-written C program can be transferred between machines
with dramatically different architectures with relatively
little effort
* there's only one-and-a-half calling conventions visible to
the programmer

And some ways it is:

* a decent compiler generates locally efficient code
* constructs don't have concealed overheads
* if you make a mistake, you can cut your metaphorical throat
* it's easy to write non-portable code, even unwittingly
* it can tempt you into micro-efficiencies

 

[Alf P. Steinbach]

* Chris Dollin:

C was designed as a portable assembly language, the most successful so
far, so if the term has any practical meaning, then C is that meaning.

I would have said it was designed as a portable language to /replace/
[the use of] assembly language(s) [for a variety of "systems programming"
uses].

C looks nothing like any assembly language I've ever seen, which I
suppose may just indicate my limited knowledge of assemblers. Calling
it "portable assembly language" is an instructive metaphor, but it
is just that - a metaphor.

Here are some ways in which C isn't like the assembly languages I've
seen:

* you don't get/need to pick which instructions get used
* you don't get/need to pick the order the instructions are in
* you don't get/need to pick the addressing modes that are used
* you don't have [complete] control over what goes into registers
* you get scoped variables
* you get typed variables [yes, some assemblers handle that]
* "basic" statements don't correspond to single instructions
* use of explicit control structures (if-then, while-do, etc)
is the norm, rather than conditional goto's
* the compiler does mandated useful consistency checking
* compilers and other tools often do additional consistency checking
* a well-written C program can be transferred between machines
with dramatically different architectures with relatively
little effort
* there's only one-and-a-half calling conventions visible to
the programmer

And some ways it is:

* a decent compiler generates locally efficient code
* constructs don't have concealed overheads
* if you make a mistake, you can cut your metaphorical throat
* it's easy to write non-portable code, even unwittingly
* it can tempt you into micro-efficiencies

You're obviously asking for more information about why your experience
with some things doesn't match your perception of what the phrase
"portable assembly language" should mean. Well, it could be your
experience (limited). Or it could be your perception (plain wrong).

Try first of all to read the Wikipedia article I linked to.

Then, accept that set phrases don't always mean what the words literally
mean in some other context(s).

 

[Andrew Reilly]

My mechanism is
hardly well thought out, it is only intended to trigger thoughts
from others. As I said, blue skying.

Thanks for the prompting.

Thinking about this made me realize that actually accessing condition
codes isn't very useful, as an end in itself. Sure, there can be
some (like half-carry, perhaps) that might be useful, but if you really
needed that, I think that some sort of in-line intrinsic could carry it
off. It's not as though it's portable, anyway.

No, the point about condition codes is that they're a means to an end, and
C already covers most of those ends with other constructs. Most of the
basic condition codes are just there to tell you if some result is zero,
or which way a comparison went (whether you consider the arguments signed
or unsigned). Ordinary control (if, while, etc) statements handle those
nicely.

Lots of embedded processors (ab)use the carry flag as a 1-bit source or
result for bit-test operations and rotates, but I've seen plenty of
compilers with a good enough library of peep-hole optimizations that will
generate the necessary bit-test/branch-on-carry sequence when given the
usual if (a & (1<<n)) idiom, or the like.

That really only leaves extended precision addition and subtraction, and
the use of addc. That can generally be accommodated through idiom or
assembly language.

Once upon a time I used to think that the inability to code directly with
reference to condition codes was terribly limiting, and that my code was
bloated and inefficient, as a result. (I coded in assembler for a
long while, before I learned C.) Now, I don't miss them. I don't know
whether that says that I'm writing different sorts of code, or just
approaching the problem differently, or missing optimization opportunities.

Cheers,

 

[Andrew Reilly]

is there someone out there that read this?
am i plonked from all NGs?

I saw your post. I feel the same way myself, even when my posts show up
in google groups. Sometimes people just don't feel the need to respond, I
guess...

Cheers,

 

[Dik T. Winter]

> Alf P. Steinbach said:
>
>
> You would do better to visit <http://www.lysator.liu.se/c/> which has a
> number of good links to well-established pages about C. The Wiki page
> suffers from being modifiable by the clueless.

But what is on it now is pretty well done.

 

[Chris Dollin]

* Chris Dollin:

C was designed as a portable assembly language, the most successful so
far, so if the term has any practical meaning, then C is that meaning.

I would have said it was designed as a portable language to /replace/
[the use of] assembly language(s) [for a variety of "systems programming"
uses].

C looks nothing like any assembly language I've ever seen, which I
suppose may just indicate my limited knowledge of assemblers. Calling
it "portable assembly language" is an instructive metaphor, but it
is just that - a metaphor.

Here are some ways in which C isn't like the assembly languages I've
seen:

* you don't get/need to pick which instructions get used
* you don't get/need to pick the order the instructions are in
* you don't get/need to pick the addressing modes that are used
* you don't have [complete] control over what goes into registers
* you get scoped variables
* you get typed variables [yes, some assemblers handle that]
* "basic" statements don't correspond to single instructions
* use of explicit control structures (if-then, while-do, etc)
is the norm, rather than conditional goto's
* the compiler does mandated useful consistency checking
* compilers and other tools often do additional consistency checking
* a well-written C program can be transferred between machines
with dramatically different architectures with relatively
little effort
* there's only one-and-a-half calling conventions visible to
the programmer

And some ways it is:

* a decent compiler generates locally efficient code
* constructs don't have concealed overheads
* if you make a mistake, you can cut your metaphorical throat
* it's easy to write non-portable code, even unwittingly
* it can tempt you into micro-efficiencies

You're obviously asking for more information about why your experience
with some things doesn't match your perception of what the phrase
"portable assembly language" should mean.

No, I wasn't. I was /giving/ information about why I felt that C
wasn't (obviously) "portable assembly language". I have no argument
that C /plays that role/: my remarks were intended to expose ways
in which the term fails.

Well, it could be your experience (limited).

I said that. You might have bothered to offer some assembly languages
more like C than the kind I had in mind.

Or it could be your perception (plain wrong).

Sorry, I missed the bit where you offered an argument.

Try first of all to read the Wikipedia article I linked to.

Amusing - it slugged my (old) copy of Konqueror and damn near my
desktop. When I firefoxed it, it didn't seem to have much to say
on the issue anyway.

Then, accept that set phrases don't always mean what the words literally
mean in some other context(s).

Gosh. I'm, like, gobsmacked - I had never imagined that was possible.

 

[Michael Jørgensen]

If s is stored in 16 bit mode in ESX with DX=0, then p=s-1 would
need to decrement ES by one and store 000F in DX.

I don't think this is what happens. Instead I think DX will wrap to FFFF,
and ES will remain unchanged.

-Michael.

 

[CBFalconer]

Thanks for the prompting.

Thinking about this made me realize that actually accessing condition
codes isn't very useful, as an end in itself. Sure, there can be
some (like half-carry, perhaps) that might be useful, but if you really
needed that, I think that some sort of in-line intrinsic could carry it
off. It's not as though it's portable, anyway.

No, the point about condition codes is that they're a means to an end, and
C already covers most of those ends with other constructs. Most of the
basic condition codes are just there to tell you if some result is zero,
or which way a comparison went (whether you consider the arguments signed
or unsigned). Ordinary control (if, while, etc) statements handle those
nicely.

I was thinking more about after the fact overflow detection, with
statements such as:

if ((a = b + c, ccd = _ccd) & OVFLOBIT) {
/* handle overflow, a value is meaningless */
}
else {
/* all is joy in Mudville */
}

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[CBFalconer]

.... snip ...

is there someone out there that read this?
am i plonked from all NGs?

You temporarily got off my list due to some changes in newsreader
software. At the first sign of more ridiculous obfuscating macros
you go right back on it. Meanwhile I am not likely to pay much
attention to anything you say.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[CBFalconer]

I don't think this is what happens. Instead I think DX will wrap
to FFFF, and ES will remain unchanged.

More easily answered if the original statement had been preserved
in context. However in this case if the ES segment has range
limits, a segment fault will be triggered. Due to the happy
looseness of the term "undefined behavior" no specific action is
needed, which is what enables the loosing of nasal demons or
launching of missiles.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Keith Thompson]

* Richard Bos -> someone:

Happily I haven't followed this debate, so I don't know what you
folks, good or not, think "portable assembler" means, nor how you can
think a language is a compiler (or whatever).

C was designed as a portable assembly language, the most successful so
far, so if the term has any practical meaning, then C is that meaning.

No, it wasn't. Quite possibly the term has no practical meaning, but
even if it does, C isn't it. C is at a lower level than most
high-level languages, but there's a *much* wider semantic gap between
assembly language and C than between C and other HLLs.

C was designed as a portable assembly language for the purpose of
porting Unix (which then had some seven or ten installations, I
forget, but one rumor has it there was only one, namely the PDP-7)
more easily. That didn't fully remove the need for using actual
assembly. But only some small parts still needed to be
machine-specific assembly.

You can find more information about the C language at e.g. Wikipedia,
<url: http://en.wikipedia.org/wiki/C_programming_language>.

I skimmed that article; it doesn't support your argument. The nearest
thing in the article is:

It is quite possible to write C code at a low level of abstraction
analogous to assembly language; in fact C is sometimes referred to
(and not always pejoratively) as "high-level assembly" or
"portable assembly".

Calling it assembly doesn't make it assembly.

Show us a definition of the term "assembly language". By
"definition", I mean something that unambiguously allows you to
determine whether something is an assembly language or not. If you do
so, I predict that either (1) your definition won't apply to C, or (2)
your definition won't match any common understanding of the term
"assembly language".

 

[Al Balmer]

* Richard Bos -> someone:

Happily I haven't followed this debate, so I don't know what you folks,
good or not, think "portable assembler" means, nor how you can think a
language is a compiler (or whatever).

C was designed as a portable assembly language, the most successful so
far, so if the term has any practical meaning, then C is that meaning.

The reference you give doesn't say that. It says "in fact C is
sometimes referred to (and not always pejoratively) as "high-level
assembly" or "portable assembly"." When they say "sometimes", they're
talking about you, not the rest of the world. Remember that the moon
is sometimes said to be made of green cheese.

C was designed as a portable assembly language for the purpose of
porting Unix (which then had some seven or ten installations, I forget,
but one rumor has it there was only one, namely the PDP-7) more easily.

In fact, from your reference, "but this was onerous since all the code
was in assembly language. They decided to use a higher-level portable
language so the OS could be ported easily from one computer to
another."

Note the use of the phrase "higher-level portable language."

That didn't fully remove the need for using actual assembly. But only
some small parts still needed to be machine-specific assembly.

You can find more information about the C language at e.g. Wikipedia,
<url: http://en.wikipedia.org/wiki/C_programming_language>.

There are better sources, including the original authors.

 

[Alf P. Steinbach]

* Keith Thompson:

Show us a definition of the term "assembly language". By
"definition", I mean something that unambiguously allows you to
determine whether something is an assembly language or not. If you do
so, I predict that either (1) your definition won't apply to C, or (2)
your definition won't match any common understanding of the term
"assembly language".

Sorry, that's bullshit.

However, show me a definition of bullshit (by "definition", I mean
something that unambiguously allows you to determine whether something
is bullshit or not) and I'll readily retract that statement. ;-)

Cheers,

- Alf

 

[Al Balmer]

is there someone out there that read this?
am i plonked from all NGs?

According to my newsreader, your first post was at 4:34 am, and your
second at 5:30 am. What were you expecting? Do you have this group
confused with a chat room?