x86 evolution for segmentation and paging

9 points by goliath

invlpg

Is the author of this a fan of Super Metroid? They're certainly careful in their choice of words.

pclouds

I looked so hard for double whitespaces. I knew he could do this (didn't know it was a thing btw) but could not believe anybody would go so far to keep text aligned.

aengelke

a PM64-only PML5-only implementation with FRED and APX that has been used at scale for >1 year. [...] for the x86S spec, Intel gave up in mid 2024. Which turned out to be premature. Someone else continued.

I'm wondering: who has an APX implementation in production for >1 year before Intel even ships their first APX CPUs? Zhaoxin has IP, but from what I've read their CPUs are far behind in terms of performance; Hygon could be a candidate having access to Zen 1 IP and distributing CPUs with at least AVX-512. Not sure who else has very recent x86 IP. (On his web site, the author hints at "EVOLUTIONARY (🅴🆅🅾︎·🅻🆄🆃·🅸🅾︎🅽·🅰︎🆁🆈™)", not sure what this is?)

There are also some very interesting bits in this e-mail:

Second, a set of 2x2 bits for controlling how FS/GS apply in supervisor mode and in user mode. (By default, the last FS or GS wins; other choices are "first one wins", "both get applied", and "both get ignored".)

This is certainly a departure from the static encoding of x86 prefixes today (for fs/gs, currently the last one wins always). This implies that the address operands of any memory accesses containing a 64/65 prefix are now dependent on a runtime config. The ability to add fs and gs bases at the same time is also interesting.

That is, the core stays in PM64-only, but instead of page table walks, you automatically get identity mapped pages (VA=PA).

I wonder if this is for startup or for avoiding translation cost and TLB misses?

Some more e-mails from Christian Ludloff referring to "a corporate entity other than Intel/AMD", most probably from the same origin:

x86 WBINVD prefix allocations, describing a unique use of prefixes for the 0f09 opcode, which is also interesting.
x86 AMX/ACE with >8 tiles
x86 opcode/CPUID/MSR allocations

invlpg

Some more fuel for the fire:

RosaicLabs has a license from Intel for Atom CPUs and appear to be building CPUs with an AI-focus. Christian has had 🌹 listed as his role on LinkedIn since 2024, but RosaicLabs has only existed officially since May of this year. Between July 2024 and June 2026 he lists the 1st at-scale x86S + APX + AVX10 + 32-tile AMX/ACE as his focus as an x86 Architecture specialist.

AMX would line up with an AI-focused chip company, but the timeline doesn't make sense unless this has been in the works stealthily for quite some time now. And cmbining Atom with APX doesn't make much sense to me unless they're doing something very strange.

Other than that I haven't been able to dig up any more than you have.

EDIT (additional speculation):

Rosaic mention GPGPU on their website, I wonder if they're working on something like the Intel Xeon Phi, with a large number of in-order Atom cores with APX and AMX extensions.
- aengelke
  
  Thanks, I somehow missed Rosaic. (This article at Chips and Cheese provides some more background.)
  
  And cmbining Atom with APX doesn't make much sense to me unless they're doing something very strange.
  
  APX makes more sense for Atom than for Xeon cores: more registers implies less spilling, three-operand form implies fewer instructions -- things that matter less on a high-end core. Probably also for compatibility.
- colejohnson66
  
  What I don't understand is why he's doing these cryptic trickles. If this is RosaicLabs and they're teasing their new chips, why? For now, all I see is a company making a super-custom x86 implementation. Especially that PG=0 (PA:=VA) and "both get applied" (for FS/GS). If the intent is for software (especially binutils and the kernel) to prepare for your chip, why post these cryptic messages instead of patches?
  - aengelke
    
    If the intent is for software (especially binutils and the kernel) to prepare for your chip
    
    Probably more "don't make certain assumptions, they may not hold in the future," and the mails seem to be pretty restricted to those lines. For active preparation, they are way to vague. Nonetheless, such information can be somewhat valuable to have early on, as it may influence certain design decisions to make later extensions easier (e.g., in my x86 decoder, I do rely on several assumptions of valid opcodes).
    
    A possible motivation: while working on or rebasing downstream modifications they encountered some difficulties and would prefer upstream to not move further away from what they need.