this post was submitted on 23 Jun 2024
276 points (94.5% liked)

Technology

59589 readers
3148 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] wewbull@feddit.uk 142 points 5 months ago* (last edited 5 months ago) (20 children)

We do, depending on how you count it.

There's two major widths in a processor. The data register width and the address bus width, but even that is not the whole story. If you go back to a processor like the 68000, the classic 16-bit processor, it has:

  • 32-bit data registers
  • 16- bit ALU
  • 16-bit data bus
  • 32-bit address registers
  • 24-bit address bus

Some people called it a 16/32 bit processor, but really it was the 16-bit ALU that classified it as 16-bits.

If you look at a Zen 4 core it has:

  • 64-bit data registers
  • 512-bit AVX data registers
  • 6 x 64-bit integer ALUs
  • 4 x 256-bit AVX ALUs
  • 2 x 128-bit data bus to DDR5 (dual edge 64-bit)
  • ~40-bits of addressable physical RAM

So, what do you want to call this processor?

64-bit (integer width), 128-bit (physical data bus width), 256-bit (widest ALU) or 512-bit (widest register width)? Do you want to multiply those numbers up by the number of ALUs in a core? ...by the number of cores on a piece of silicon?

Me, I'd say Zen4 was a 256-bit core, but you could argue any of the above numbers.

Basically, it's a measurement that lost all meaning so people stopped using it.

[–] ulterno@lemmy.kde.social -1 points 5 months ago (4 children)

I see it as the number of possible instructions.

As in, 8 bit 8085 had 2^8^ possible instructions, 32 bit ones had 2^32^ and already had enough possible combinations that we couldn't come up with enough functions to fill the provided space.

CC BY-NC-SA

[–] wewbull@feddit.uk 5 points 5 months ago (3 children)

So "instruction encoding length".

I don't think that works though. For something like RISC-V, RV64 has a maximum 32-bit instruction encoding. For x86-64 those original 8-bit intructions still exist, and take up a huge part of the encoding space, cutting the number of n-bit instructions to more like 2^(n-7)

[–] ulterno@lemmy.kde.social 0 points 5 months ago (1 children)

RV64 has a maximum 32-bit instruction encoding

I kinda expected that to happen, since there's already enough to fit all required functions. So yeah, even this is not a good enough criteria for bit rating.

those original 8-bit intructions still exist, and take up a huge part of the encoding space, cutting the number of n-bit instructions to more like 2^(n-7)

err... they are still instructions, right? And they are implemented. I don't see why you would negate that from the number of instructions.

[–] wewbull@feddit.uk 2 points 5 months ago (1 children)

If the 8088 had used all but one 256 8-bit values as legal instructions, all your new instructions after that point would need to start with that unused value and then you can add a maximum of 256 instructions by using the next byte. End result is 511 instructions can be encoded in 16-bits.

[–] ulterno@lemmy.kde.social 0 points 5 months ago

Ah right! I forgot about that.

So you either have to pad all instructions in all previous binaries, or reduce the amount of available instructions in the arch update.

load more comments (1 replies)
load more comments (1 replies)
load more comments (16 replies)