Why bool take 1 byte?

[Joel Yliluoma]

Obviously you mean
A tmp;
std::swap(tmp.a, tmp.c);
?

Yes, sorry.

 

[James Kanze]

The fact that a Z80 actually had to read or read/modify/write an
entire 8-byte byte to test, set, or clear a single bit was completely
immaterial from an architectural point of view, that's a hardware
implementation detail.

Would you claim that a Pentium was not "really" byte addressable,
because it will read a minimum of 64 bits from memory to change the
value of just one of them?

But it won't write the others, even if it reads them.

Given:

char ca [8] = { 0 };
++ca[4];

...the processor hardware will execute at least two 64-bit bus
cycles, reading the entire contents of the array if it is
suitably aligned to get at ca[4]. If it winds up in the
cache, it will eventually write all 64 bits back to memory,
even though only one 8-bit octet is changed.

Are you sure of this? If so, it makes multithreaded code pretty
much impossible, at least with the usual definitions. Thread 1
(on processor 1, with cache 1) reads the array, and modifies
ca[4]. Thread 2 (on processor 2, with cache 2) reads the array,
and modifies ca[3]. The last one to write overwrites the
other's modification. According to Posix (and the upcoming C++
standard), no external synchronization is necessary, because
different C++ objects are being modified. (Note that while
Posix isn't too clear about this, the upcoming C++ standard will
clearly state that different bit fields in the same struct are
not different objects.)

set 0,(hl)

...on a Z80 was a single, and atomic, instruction, regardless
of what the hardware did to make it happen.

IIRC, the Z80 didn't have any hardware support for atomic
operations between processors. So it was only atomic within a
processor.

 

[Juha Nieminen]

Are you sure of this? If so, it makes multithreaded code pretty
much impossible, at least with the usual definitions. Thread 1
(on processor 1, with cache 1) reads the array, and modifies
ca[4]. Thread 2 (on processor 2, with cache 2) reads the array,
and modifies ca[3]. The last one to write overwrites the
other's modification.

Processors (well, more accurately the cache management logic) are
smarter than that. They can detect if a portion of memory cached in two
different processor caches has been modified by the other processor.
(This will of course cause clock cycle penalties while the caches are
synchronized, but it will not cause a malfunction.)

 

[James Kanze]

Are you sure of this? If so, it makes multithreaded code pretty
much impossible, at least with the usual definitions. Thread 1
(on processor 1, with cache 1) reads the array, and modifies
ca[4]. Thread 2 (on processor 2, with cache 2) reads the array,
and modifies ca[3]. The last one to write overwrites the
other's modification.

Processors (well, more accurately the cache management logic) are
smarter than that. They can detect if a portion of memory cached in two
different processor caches has been modified by the other processor.
(This will of course cause clock cycle penalties while the caches are
synchronized, but it will not cause a malfunction.)

You mean when it goes to write the memory back from cache? That
the processor detects that its image is not consistent with that
in main memory?

I've not looked at that level (only at the formal guarantees
provided by the architecture), but somehow, I'm sceptical. What
would the processor do if it detects that the byte had been
modified both in its own cache, and in the main memory?

(At the level of formal guarantees, modifying ca[4] on one
processor, and ca[3] on the other, is guaranteed to work without
any external synchronization. Although I'm aware of at least
one very old processor where that wasn't the case.)

 

[Juha Nieminen]

You mean when it goes to write the memory back from cache? That
the processor detects that its image is not consistent with that
in main memory?

No. I mean that when two processors, each one with their own L1 cache,
have the same memory block cached, when one of the processors change the
memory location, the other processor (well, more specifically its cache
logic) detects this change and invalidates the data in its own cache.

SMP-multithreading with multiple processors obviously couldn't
function properly without this kind of logic.

IIRC modifying a shared memory location is an atomic operation even in
a multi-processor system (well, at least in the intel architecture), so
two modifications of the same memory location are guaranteed never to
happen exactly at the same time. (Don't shoot me if I'm remembering
wrong here, but I'm pretty certain it was this way.)

 

[terminator]

Yes, I would recommend std::bitset, but that would not answer the
question.

oops!! I was driving too fast.

 

[James Kanze]

No. I mean that when two processors, each one with their own
L1 cache, have the same memory block cached, when one of the
processors change the memory location, the other processor
(well, more specifically its cache logic) detects this
change and invalidates the data in its own cache.

But not instantaneously. That sort of synchronization takes a
finite amount of time.

SMP-multithreading with multiple processors obviously couldn't
function properly without this kind of logic.

It seems to.

Seriously, if you don't take any precautions, there's no
guarantee with regards to when you'll see a write from another
processor. But of course, if any thread is writing, then any
non-synchronized access is undefined behavior; you need to use
some sort of synchronization primitive---in all threads---to
ensure that the reading threads see the writes.

IIRC modifying a shared memory location is an atomic operation even in
a multi-processor system (well, at least in the intel architecture),

I'm not sure what you mean by that. A single write is always
atomic, but that doesn't mean that other processors see it
immediately. Even in the Intel architecture. (I think that the
current Intel definitions do guarantee more or less rapid
propagation if the writing instruction is prefixed with a lock.)

so two modifications of the same memory location are
guaranteed never to happen exactly at the same time. (Don't
shoot me if I'm remembering wrong here, but I'm pretty certain
it was this way.)

Two modifications can't possibly6 occur at exactly the same
time, obviously. On the other hand, there's not much guarantee
with regards to ordering: you can't normally tell which one will
occur first. And of course, a finite time passed between the
write and the moment another processor is aware of it.

 

[webinfinite]

Because a byte is the smallest addressible unit in the language.

Consider:

bool foo;
bool *pfoo = &foo;
If a bool consists of a single bit, now what?

Of course, you can make your own bit sets very easily if you like (to
conserve space).

Sorry for my bluntness. I don't think this is a good example. Because
here pfoo is a pointer to a bool, itself is not a bool. foo could be
one bit but its address can be a byte (In modern OS, the address shall
be 4 bytes or more). I think bool is not 1 bit is because the
compiler fetch data and instruction based on bytes. Even you implement
your bool as 1 bit, the whole address location will be fetched while
the code is running.

Using bitset is one way to use limited memory to do more work such as
sorting.

 

[terminator]

No. I mean that when two processors, each one with their own L1 cache,
have the same memory block cached, when one of the processors change the
memory location, the other processor (well, more specifically its cache
logic) detects this change and invalidates the data in its own cache.

SMP-multithreading with multiple processors obviously couldn't
function properly without this kind of logic.

IIRC modifying a shared memory location is an atomic operation even in
a multi-processor system (well, at least in the intel architecture), so
two modifications of the same memory location are guaranteed never to
happen exactly at the same time. (Don't shoot me if I'm remembering
wrong here, but I'm pretty certain it was this way.)

what if two processors almost simultaniously change contents of their
cache locations that represent the same memmory location?
If I am not wrong this is a semaphore handled via hardware or master
processor`s software . I guess cached portion of memory needs be
locked(write-protected('const'ed) in better words) when one processor
uses(read/writes) its cache so that the second processor is
banned(interupted) from writing to its cache in case of referencing
cache location representing an address in the portion of memmory
cached by the first processor.

just my guess,
FM.

 

[terminator]

what if two processors almost simultaniously change contents of their
cache locations that represent the same memmory location?
If I am not wrong this is a semaphore handled via hardware or master
processor`s software . I guess cached portion of memory needs be
locked(write-protected('const'ed) in better words) when one processor
uses(read/writes) its cache so that the second processor is
banned(interupted) from writing to its cache in case of referencing
cache location representing an address in the portion of memmory
cached by the first processor.

just my guess,
FM.- Hide quoted text -

- Show quoted text -

too late, too silly