Re: Computer architects leaving Intel...

On 17/09/2024 12:15, Michael S wrote:

On Tue, 17 Sep 2024 11:29:15 +0200
David Brown <david.brown@hesbynett.no> wrote:
 

On 17/09/2024 03:36, Waldek Hebisch wrote:

David Brown <david.brown@hesbynett.no> wrote:

On 16/09/2024 19:51, MitchAlsup1 wrote:

On Mon, 16 Sep 2024 8:34:19 +0000, David Brown wrote:
 

On 15/09/2024 21:13, MitchAlsup1 wrote:

>
As to HW sadism:: this not not <realistically> any harder than
mis- aligned DW accesses from the cache. Many ISA from the
rather distant past could do these rather efficiently {360
SRDL,...}

>
Anyone who designs a data structure with a bit-field that spans
two 64-bit parts of a struct is probably ignorant of C
bit-fields and software in general.  It is highly unlikely to be
necessary or even beneficial from the hardware viewpoint, but
really inconvenient on the software side (whether you use
bit-fields or not).

>
Sometimes you don't have a choice::
x86-64 segment registers.
PCIe MMI/O registers,
..

>
The folks designing those register setups had a choice, and made a
bad choice from the viewpoint of software (whether it be C,
assembly, or any other language).
>
It's conceivable that it was the right choice on balance,
considering many factors.  And it's certainly more believable that
it was an appropriate choice when sizes were smaller.  It is less
believable that there is an overwhelming need to cross a 64-bit
boundary.

>
Several pieces of software discoverd that "bad" smaller data
structures lead to faster execution.  Simply, smaller data
structures lead to better utilization of caches and busses, and
efect due to this was larger than cost of extra instructions.  So
need to cross 64-bit boundary may be rare, but there will be cases
when it is best choice.
  

>
It is possible, but I think it is rare.
>
Perhaps my perception is biased from working with microcontrollers,
where you often don't have caches and instruction speeds are not
nearly as much faster than ram access speeds as you see in modern x86
systems.

 On the other hand, with MCUs it's quite common to be limited by size of
data storage (SRAM), while size of program storage (flash) is bigger
than one will ever want. Plus, quite often, speed is of less concern.
In such [common] situation densely packed [arrays of] structures could
be desirable.

That can also be true.  (The smallest device I ever used had 1 KB of flash, and that was still plenty for the task I had!)
But in many embedded systems, speed is of some concern at least - if you can do the task in fewer clock cycles, maybe you can use a slower device (which might be cheaper, or have easier EMC requirements), or you can spend more time in sleep modes for reduced average power.  Run-time efficiency isn't always about shorter wall-clock times.
The main thing about embedded development, however, is that the answer is always "it depends".  There are few hard and fast rules!

 

>
The other thing I don't like about split bit-fields is that there is
typically no way to do atomic updates, which can mean you need extra
care to keep things correct.
>

 In the common case, on common ISAs atomic RMW update of bit field is
impossible even when the field does not cross a word boundary.
 In case you mean write-only update (i.e. values of adjacent fields are
known in advance and not expected to change), what you say can be
correct or not, depending on availability of unaligned stores and on
what exactly one consider 'atomic'.
 

Yes, these are all possibilities.  But it is not uncommon that the key thing is to avoid partial updates where you have changed one half of a hardware register but not yet changed the other half.