Absense of bool

[Chris Dollin]

Yup all very C-like.

Was somebody asking for /C-like/ GCed languages? And what does "C-like" mean,
in the era before C?

 

[Chris Dollin]

As is smearing ketchup all over your printouts I'm sure.

I'm not. I really do mean that "interpreting assembler" is a
reasonable thing to do in some circumstances, and gave a clue
in the usual place. Try thinking of a /constructive/ reason.

 

[Richard]

Was somebody asking for /C-like/ GCed languages? And what does "C-like" mean,
in the era before C?

We are talking about GC for C. Not for Lisp. Not for Algol. This is
getting to look like one of those fighting for points threads. I'll bow
out.

There was no need and no desire for GC in C. It would be like hanging an
anchor off the back of a skateboard.

 

[Richard]

I'm not. I really do mean that "interpreting assembler" is a
reasonable thing to do in some circumstances, and gave a clue
in the usual place. Try thinking of a /constructive/ reason.

In what out of the way instances would interpreting assembler mnemonics(assembler
here, not the opcodes) be seen as a suitable need for including GC in C?

 

[Chris Dollin]

In what out of the way instances would interpreting assembler mnemonics(assembler
here, not the opcodes) be seen as a suitable need for including GC in C?

You introduced the analogy. (Whether it's machine opcodes or assembler
mnemonics one is interpreting is a "mere detail" as far as my claim of
reasonableness is concerned; it took the point to be one of interpretation
vs direct execution. Was I wrong?) I didn't think you were meaning to
say that interpreting assembler was a reason for having a GC'd C; did
I misread you?

 

[Chris Dollin]

We are talking about GC for C. Not for Lisp. Not for Algol.

It was you, was it not, who asked "What languages used GC at the time that
C and its forefathers were evolving?" Someone -- I've lost track of who --
claimed that "it didnt exist when C was invented". They were wrong, and I
took you to be asking for examples.

I answered that question.

There was no need and no desire for GC in C.

I've not said otherwise (and I think that "was" may be important).

It would be like hanging an anchor off the back of a skateboard.

Indeed.

One doesn't get motorcycles by merely adding engines to bicycles; effective
language design is holistic.

 

[jameskuyper]

In what out of the way instances would interpreting assembler mnemonics(assembler
here, not the opcodes) be seen as a suitable need for including GC in C?

The original comment compared "Putting GC into C" with "interpreting
assembler" as being equally ridiculous things to do. it was not about
using the later as a reason for the former. The comment "A perfectly
reasonable thing to do, in some circumstances" was ambiguous: it
probably referred to "interpreting assembler", it might have referred
to "Putting GC in C", and it may have been deliberately ambiguous
because it was actually referring to both. However, it did not in any
sense suggest a connection between those two features.
..

 

[santosh]

In what out of the way instances would interpreting assembler
mnemonics(assembler here, not the opcodes) be seen as a suitable need
for including GC in C?

I believe Chris said that interpreting assembler would be perfectly
reasonable in some circumstances, not that that means that using a GC
with C is also equally reasonable.

One example I can mention of the top of my head is the famous MIX
assembler language developed by Donald Knuth for his invaluable _Art of
Computer Programming_ series. There is no, AFAIK, real machine
implementing the MIX instruction set, so several interpreters have been
developed.

Similarly many out-of-production architectures have
interpreters/emulators that still allow their aficionados to enjoy
them.

 

[Guest]

I don't claim that this is the first paper on GC, just that it
pre-dates C. There are dozens of papers about GC from the 60s and DMR
cites 1969-73 as the key design time for C.

Ok. Thank you for the information...

I was basing on Richard's words when I wrote that (I didn't know when GC
had been invented).

JJ

 

[Charlie Gordon]

There is no multibit boolean type, you are erecting straw men and
knocking them down yourself. The programmer can use his own with no bits
wasted if he so chooses.

[...]

Can you clarify that statement?

I'll ignore bit fields in the following; note that bit fields can only
be members of structs or unions, so they're not useful if you want to
declare single object.

All C types are multi-bit. Every C object has a size that's a whole
number of bytes, where each byte must be at least 8 bits. If you
declare an object of a boolean type, whether it's C99's _Bool or
soemthing you've defined yourself, that object must occupy at least 8
bits. Note that C doesn't have zero-sized objects.

(This "waste" of space isn't a problem in practice; using only a
single bit would typically require much more code to access it than
the data space you'd save.)

I see no straw man argument in what santosh posted above.

If you think that a programmer "can use his own [boolean type] with no
bits wasted if he so chooses", please demonstrate how you'd declare
such a type.

With C as currently standardized, the programmer would have to implement
some sort of byte based type where s/he can store packed bit values through
a macro or function based interface:

/* assuming no padding */
static inline int setbit(unsigned char *buf, unsigned off, int val) {
if (val) {
buf[off / CHAR_BIT] |= 1U << (off % CHAR_BIT);
return 1;
} else {
buf[off / CHAR_BIT] &= ~(1U << (off % CHAR_BIT));
return 0;
}
}

This is cumbersome, error prone, and potentially inefficient.

It would be much more convenient if bitfields could have been made
standalone types, and support added for arrays of such types:

typedef unsigned flag_t : 1; // or possibly
typedef unsigned : 1 flag_t;
flag_t status_buf[FLAG_COUNT]; // or direclty
unsigned : 1 status_buf[FLAG_COUNT];

Or course, it would still be a constraint violation to try and take the
address or the size of a flag_t object, but address and sizeof status_buf
would be OK. There could also be some padding involved to make the
implementation of arrays of bitfields more efficient, such as padding them
to a number of bits that is a divisor of the width of some integer type when
packed into an array.

I did not see anything in the Standard regarding arrays of _Bool, but
implementations such as gcc suggest sizeof(_Bool) == 1 and arrays of _Bool
are essentially arrays of unsigned chars. This results in a waste factor of
8 over arrays of bits. Depending on the application, this can be
significant or not.

 

[David Thompson]

On Sun, 04 Nov 2007 09:53:31 +0000, Philip Potter

Do you have an example of a language with a boolean type which will
store the boolean in a location smaller than a byte?

Pascal can use only 1 bit for a BOOLEAN and only the needed bits for a
(small) subrange or enum within an array or record, especially if you
declare it PACKED. At least in classic Pascal there is no way to take
the address of these so it doesn't matter that they aren't on a byte
(or word) boundary.

PL/I can do both of those for BIT(1), but AFAIK there's no syntax to
specify packing, so IMLE it is usually the default. (You can
explicitly declare padding, but it's hard to get it portably correct.)
PL/I also has BIT strings (fixed or variable-length=counted) which are
inherently packed, and whose elements cannot be pointed to (but can be
selected by SUBSTR).

Ada rather like Pascal has BOOLEAN and subrange/enum types, a general
option (pragma) for packing, and also more verbose options for exact
representation which allow you to really force desired packing.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Bart]

How would it save resources? A boolean type smaller than char would
require more resources to implement and at run time. How would it make
coding any prettier?

An array of Bool could save considerable resources, typically 87.5%,
if implemented as a bit-array. There would be implementation issues in
C however as a bit wouldn't be directly addressable.

Bart

 

[Bart]

An array of Bool could save considerable resources, typically 87.5%,
if implemented as a bit-array. There would be implementation issues in
C however as a bit wouldn't be directly addressable.

Bart

Sorry I didn't realise this thread is 3 weeks old.

Bloody Google showing this near the top because of a late post. (Will
be even nearer the top now.)

 

[Chris Hills]

An array of Bool could save considerable resources, typically 87.5%,
if implemented as a bit-array. There would be implementation issues in
C however as a bit wouldn't be directly addressable.

Some MCU have directly addressable bit types and you can save a lot of
resources.

However in most MCU that will not work with anything less than a byte
you are going to have to do a code work around.... SO you have to
balance the speed of using a byte per bool or the memory saving of a
bit per bit and have it slower and a bit more code.