The Motorola 68000 register file was split into address and data. This had some useful properties, most obviously that load/store only needed three bits instead of four to specify an address register.

One feature was that operations on address registers did not update the status bits. The argument was that this was useful because you could do arithmetic, load/store, then branch on the results of the arithmetic.

My vague understanding of how status bits work is that they are cheap to provide because you don't need to add microinstructions to update them on every operation, you just have small circuits watching an internal bus on the chip, so once you have them, it's basically free to have them updated on every operation.

(Until you start going out of order, but that's much later.)

Given that, it would seem that the 68000 would need an extra few logic gates to not update the status bits if you have just been operating on an address register.

Is that correct, or am I missing something?

On Thursday, July 6, 2023 at 2:57:40 PM UTC-5, Russell Wallace wrote:
> The Motorola 68000 register file was split into address and data. This had some useful properties, most obviously that load/store only needed three bits instead of four to specify an address register.
<
While this helps with encoding entropy, it hurts on the number of instructions one has to execute.
Overall, doing no better than break even (total instruction byte count).
>
> One feature was that operations on address registers did not update the status bits. The argument was that this was useful because you could do arithmetic, load/store, then branch on the results of the arithmetic.
<
The counter argument is if you ever want to do Great Big OoO then it hurts big time.
>
> My vague understanding of how status bits work is that they are cheap to provide because you don't need to add microinstructions to update them on every operation, you just have small circuits watching an internal bus on the chip, so once you have them, it's basically free to have them updated on every operation.
<
You should also add that teaching a compiler how to use them is not-straightforward,
and you can argue that no status flags are equally good (or better) entomologically.
>
> (Until you start going out of order, but that's much later.)
>
> Given that, it would seem that the 68000 would need an extra few logic gates to not update the status bits if you have just been operating on an address register.
<
68000 was a 32-bit PDP-11 with partitioned A+D registers packed onto a single chip
with 24-bit address bus and 16-bit data bus.
>
> Is that correct, or am I missing something?

On Thursday, July 6, 2023 at 4:27:51 PM UTC-4, MitchAlsup wrote:
> On Thursday, July 6, 2023 at 2:57:40 PM UTC-5, Russell Wallace wrote:
> > The Motorola 68000 register file was split into address and data. This had some useful properties, most obviously that load/store only needed three bits instead of four to specify an address register.
> <
> While this helps with encoding entropy, it hurts on the number of instructions one has to execute.
> Overall, doing no better than break even (total instruction byte count).
> >
> > One feature was that operations on address registers did not update the status bits. The argument was that this was useful because you could do arithmetic, load/store, then branch on the results of the arithmetic.
> <
> The counter argument is if you ever want to do Great Big OoO then it hurts big time.
> >
> > My vague understanding of how status bits work is that they are cheap to provide because you don't need to add microinstructions to update them on every operation, you just have small circuits watching an internal bus on the chip, so once you have them, it's basically free to have them updated on every operation.
> <
> You should also add that teaching a compiler how to use them is not-straightforward,
> and you can argue that no status flags are equally good (or better) entomologically.
> >
> > (Until you start going out of order, but that's much later.)
> >
> > Given that, it would seem that the 68000 would need an extra few logic gates to not update the status bits if you have just been operating on an address register.
> <
> 68000 was a 32-bit PDP-11 with partitioned A+D registers packed onto a single chip
> with 24-bit address bus and 16-bit data bus.
> >
> > Is that correct, or am I missing something?

IDK exactly how the 68k works, but in my own rendition for instructions which update
the status flags there is a variable called ‘flag_update’ which contains a pattern for
flag updates. There are about 20+ different patterns of flag updates. The flag update
pattern is set for every instruction needing to update flags. So, it is not very expensive
not to update the flags. It is just setting the ‘flag_update’ that is omitted.
Conversely, flag updates for instructions needing to update flags are relatively
expensive compared to a machine that does not have any flag registers.

Flags are updated during the instruction fetch for the next instruction in rf68k.

On Thursday, July 6, 2023 at 10:08:40 PM UTC-5, robf...@gmail.com wrote:
> On Thursday, July 6, 2023 at 4:27:51 PM UTC-4, MitchAlsup wrote:
> > On Thursday, July 6, 2023 at 2:57:40 PM UTC-5, Russell Wallace wrote:
> > > The Motorola 68000 register file was split into address and data. This had some useful properties, most obviously that load/store only needed three bits instead of four to specify an address register.
> > <
> > While this helps with encoding entropy, it hurts on the number of instructions one has to execute.
> > Overall, doing no better than break even (total instruction byte count)..
> > >
> > > One feature was that operations on address registers did not update the status bits. The argument was that this was useful because you could do arithmetic, load/store, then branch on the results of the arithmetic.
> > <
> > The counter argument is if you ever want to do Great Big OoO then it hurts big time.
> > >
> > > My vague understanding of how status bits work is that they are cheap to provide because you don't need to add microinstructions to update them on every operation, you just have small circuits watching an internal bus on the chip, so once you have them, it's basically free to have them updated on every operation.
> > <
> > You should also add that teaching a compiler how to use them is not-straightforward,
> > and you can argue that no status flags are equally good (or better) entomologically.
> > >
> > > (Until you start going out of order, but that's much later.)
> > >
> > > Given that, it would seem that the 68000 would need an extra few logic gates to not update the status bits if you have just been operating on an address register.
> > <
> > 68000 was a 32-bit PDP-11 with partitioned A+D registers packed onto a single chip
> > with 24-bit address bus and 16-bit data bus.
> > >
> > > Is that correct, or am I missing something?
> IDK exactly how the 68k works, but in my own rendition for instructions which update
> the status flags there is a variable called ‘flag_update’ which contains a pattern for
> flag updates. There are about 20+ different patterns of flag updates. The flag update
> pattern is set for every instruction needing to update flags. So, it is not very expensive
<
Opteron (AMD's first 64-bit x86) tracked the flags in 3 groups C, O, and ZAPS.
<
So your typical 2-operand instruction has 2 things to track register deliveries
in its reservation stations, and 3 to track the 8-bits of flags. Thus, flags are
expensive--more expensive (and power consuming) that waiting for a register
to be delivered.
<
> not to update the flags. It is just setting the ‘flag_update’ that is omitted.
> Conversely, flag updates for instructions needing to update flags are relatively
> expensive compared to a machine that does not have any flag registers.
<
It is not the update/no-update it is that they are coming from all over the
place. And every waiting instruction has to have the ability to capture
any or all of them.
>
> Flags are updated during the instruction fetch for the next instruction in rf68k.