David Hess (davidwhess.delete@this.gmail.com) on November 20, 2020 6:35 pm wrote:
> Maynard Handley (name99.delete@this.name99.org) on November 19, 2020 8:22 pm wrote:
> >
> > OK guys, M1 time is over. What's next?
>
> I was thinking about that the other day.
>
> How large is Apple's market for desktops as opposed to laptops and other portable devices? They
> seem to be a smartphone company that happens to make some PCs. If their desktop market cannot
> support the development of a separate CPU, which seems likely, then they will design an improved
> CPU for the portable market and adapt it as best they can for their desktops. Why split their
> resources when the desktop is dead? Smartphones and tablets are where their money is.

I don’t think Apple has the volume to justify a 5 MHz fireball for desktop, and the current chip is better than everything Intel sells anyway. Lack of a ARM desktop is glaring.

Server is a whole different question, the existing chip is great, you just need to plop down lots of them with some support that Apple is clearly capable of doing. But again Apple does not have the volume to do more than a pair or quad of the existing chips.

Will Apple get into the server market as a white box supplier so that Apple can sell a desktop with 32+ cores on a chip?

> This is in contrast to Intel and AMD who develop for the desktop market and adapt
> for the server and portable markets. Both have run concurrent development for
> lower power applications in the past but that has never turned out well.

I have long brow beated Intel for not designing a 3 GHz chip for mobile, cheap ass morons they are. But to go wider x86 decoding becomes expensive in area and heat. x86 is stuck between a rock and a hard place, something has to give.

If x86 stays stuck then ARM will pass it by in the next half decade.

Will x86 be forced to change to a fixed width instruction format, or at least something easier to decode?

32 bit opcodes are getting tight, how about 3+3 byte opcodes page aligned, 3 bytes is good for integer opcodes and 6 bytes gives you a big FPU register file with 4 operands, and all the oddball x86 add from memory stuff with bigger offsets. Yes you can do add from memory as two 3 byte opcodes but that burns a visible register, etc. RISC is stupid today, the way forward is more complex instructions to reduce code path lengths, etc.