Re: Why INFINITE loop in a thread occupy so much CPU time??

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

The language was Bliss, designed in 1969 at CMU. I used it for about 15 years. The
choice was based on the fact that in the original architecture it was designed for,
testing the low-order bit was very efficient, and the decision was that this was also a
platform-independent representation.

Also, some languages only recognize negative integers as true and 0 and positive integers
are false (they check the sign bit). Pascal was such a language in some of its
implementations. Except for those implementations where negative meant false and 0 or
positive meant true. Except on those platforms that had one's complement arithmetic
where there were distinguishable -0 and +0 (I once worked on one where -0 != 0 != +0 !=
+0. Really! The bits were CBA8421M. M was not involved in the tests, C was parity. -0
was B. +0 was CBA. There was a +0 which was A, but it could not be generated by the ALU,
but if seen it was +0. 0 was C. And there was no test that said ==0, because to get this
you had to compare the value to 0, and the -1 and the two +0s were not only unequal to
each other, they were unequal to 0).

This means that each interface must do marshalling of values which are not compatible, but
this is basically a requirement of all interface specifications. Code in the same
language on the same machine is marshalled trivially, everything else is negotiable.
joe

On Mon, 19 Nov 2007 12:33:59 -0000, "Les" <l.neilson@xxxxxxxxxxxxxxxxxxx> wrote:

A real killer comes with mixed language programming (a world in which I have
lived for many years) and passing variables, boolean especially, from one
language to another.
Different compilers may have different representations for true/false.
I heard some time ago about a compiler (details unknown) which IIRC
recognised odd integers as "true" and even integers (and zero) as "false"
thus conflicting with another language which only recognised "1" as "true"
and "0" as "false".

This way lies madness Ahahahahahaaaa!
Les

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:rmpsj3p6oeoavqta6i1dlccmsafj67cd96@xxxxxxxxxx
I know that. Back when I was a C programmer in the early 1980s, I defined

boolean.h
typedef int boolean;
#define true 1
#define false 0

Using integer types instead of a boolean type is essentially slopping
programming. This
is in the same class as people writing
int flag;
and then writting
flag = 1;
or
flag = 0;
to change a boolean value. It is habit that too many bad C programmers
seem to develop,
since they learned C from K&R first edition. Since I learned to program
in real languages
that had a boolean type, I decided that using integers to represent
boolean values was a
really stupid idea. I wrote a few C programs in the 1970s, but decided
the language was
apalling. K&R C really was an apalling language. ANSI C was the first
respectable
instance of the language, and C++ is of course much better. But I find
programmers using
the antiquated concept that integers should be used to represent boolean
values even
today.

I consider any compiler that diagnoses while(TRUE) to be worthy of a
warning to be a
compiler that does not understand reality.
joe

On Fri, 16 Nov 2007 05:34:47 -0500, David Wilkinson
<no-reply@xxxxxxxxxxxx> wrote:

Joseph M. Newcomer wrote:
Perhaps because you asked it to? If you write a computation that
consumes all the CPU, it
is going to, guess what, consume all the CPU! And that's what you've
written! So
presumably you WANT to consume 100% of the available CPU time.

I have no idea what while(1) means anyway. while(TRUE) makes sense;
while(true) makes
sense. What's an integer got to do with it?

Joe:

Well, while(1) and while(TRUE) are in fact the same thing. while(1) is
often used in C where there is no bool type.

I agree that while(true) is preferred, but all these constructs produce
warnings in recent VC versions at level 4 (at least in C++ mode), and
the preferred usage is for(;;). I find this ugly, but have started using
it since I started compiling at level 4.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: casts
    ... This is why most shit programmers refuse to learn languages including ... C Sharp and Java. ... compiler in a later edition of Visual Basic, ... language for processing data. ...
    (comp.lang.c)
  • Re: RFC : SOME IDEAS FOR THE APPLE II FPGAers
    ... that only a few system programmers really needed. ... After porting a compiler to a new machine, ... use the other half of the machine's memory for profile counters ... etc. and hand craft the critical sections in assembly language. ...
    (comp.sys.apple2)
  • Re: Aspiring highest-order programmer
    ... > syntax when in fact the abstract rules of the language define the ... The result in my experience is that a BROKEN compiler can ... programmers will avoid such things, ...
    (comp.programming)
  • Re: Multiple assignment
    ... > on language design from someone else who understands it to this ... > compiler can achieve the same quality of generated code without ... I think that most programmers' idea of "efficiency" ... functionality out of every line of code, ...
    (microsoft.public.vb.syntax)
  • Re: PL/I string representations
    ... > C is an outdated language. ... the discussion on the D level compiler from multiple sources ... Literally thousands of programmers can be extremely successful ... specifically as a result of arbitrary string length ...
    (comp.programming)