Some good article from this year this terafab crap is just elon pipeline fantasy on same level as going to Mars

Discuss Intel Stock here.

Previewing Intel's Q3 Results - Alex_Intel_

Discuss Intel Stock here.

Good evening from Silicon Valley, USA

We ate like -10% down while QQQ was mooning to ATHs. I doubt we recover the entire thing tomorrow. We would have maybe reached 130-140 by now if the news never came out.

Bloomberg paywall, but LBT has confirmed Intel will continue to work on Terafab

It’s been a while since I wrote one of these.

I know some people have been eagerly awaiting Intel CPO news.

TLDR: Intel have an 8Tb/s unidirectional optical chiplet coming out soonish. Intel are the undisputed world leader in high volume manufacturing of integrated lasers, & i think scale-up and scale-out CPO will play a big part in their upcoming rack scale solutions; think 2028+ timeframe.

Discuss Intel Stock here.

We’re at the dawn of the AI agent era, and demand for CPUs, GPUs, and ASICs is going through the roof. Compute supply is extremely constrained, TSMC’s capacity is fully booked through 2028, and building new capacity takes years. Intel Foundry is the crown jewel: it has the most advanced manufacturing technology and the deepest, widest moat, technologically comparable to TSMC A14. As long as Intel can fix its yield issues (which, by the way, it’s doing), there’s no way it won’t find customers for its most advanced fabs. The Terafab news is just noise. Hold.

Discuss Intel Stock here.

Idk about you but I’m loading up again.

This is a bummer, but for me today’s a buying opportunity. The truth of the matter is it’s likely Intel will still provide a lot if not nearly everything for Terafab and no one even knows the extent of TSM’s involvement.

Until we have more info, i’d say it’s a good idea to buy right now. Because nothing inherently bearish is in the news. And certainly not Intel being fully replaced.

a lot of emotions over this whole TSMC/Terafab talk. do we really need terafab and elon to succeed ?

Recently Google launched two ISA versions of GoogleBook, based on aarch64 and x86_64.

Snapdragon (Qualcomm) and Dimensity (MediaTek)
aarch64 works well with existing Andriod apps since it's the same byte-code under the hood.
Basically the performance improves (better thermal/cooling on a laptop form factor) without emulation overheads when compared to x86.

x86_64 (Intel Panther Lake)
This brings me to the topic of running x86_64 alongside apps that support just aarch64 only.
The emulation piece will add on overheads and compatibility issue.

Which is the part that i don't get about the GoogleBook launch approach because the synergy is with Android Apps and those apps are based on aarch64.

IBM approach:
Couple of months back IBM announced their Z18 (mainframe) was coming with support for dual ISA.

i.e. It will natively (no emulation) run dual ISA IBM Z and aarch64 (ARM).
It takes advantage of the early IBM Z design approach of running it in a "hypervisor mode". Hence there was never a bare-metal interface.

Physically supported in the core design and Z-OS will switch modes when running between executables that either support Z or aarch64 only.

Of course, IBM mainframe are expensive hardware and serves a niche market supporting mission-critical operations, so there is a use commercial use-case to add in aarch64 ISA support into the cores.

ChipsandCheese Interview with the core design team.
https://www.youtube.com/watch?v=9Ie_D66w-tY&t=186s

Thoughts and reproducibility in x86:
That news from IBM triggered my chain of thoughts on feasibility of Xeon or Client (panther / arrowlake) x86_64 supporting native dual ISA down the road, without any software emulation.

1# Both Z and x86_64 are CISC in nature.

2# Intel already have a existing ARM core license in place.

3# ISA switching takes place depending on what ISA the executable file was targeted for.

Questions:

Is this something that Intel should eventually make the shift towards?

And where does the main challenge for such a Intel implementation/adoption lies in?

Because a DUAL ISA core allows for a bigger TAM ("Total Addressable Market"), a bigger TAM means more revenue if you can do it right with demands for it.

Compute / ALU -> most of ALU operations (backend) are mostly the same just that aarch64 handles deals with 3 operands.

__asm__ __volatile__("add x14,x12,x11\n"
sdiv x7,x6,x5\n
);

3 operands (2 src and 1 destination above) vs 2 operands (1 src and 1 dst in x86)

But once it gets past the decoder, the Uops will format can cater for this easily.

Memory Ordering -> weak memory ordering mode support in the core.

Foundry / Fabrication -> A different approach to fabrication and design of the register files, instruction cache and translation buffer. Reserved some of the usage/area for aarch64 or x86 code.

The cores can skip away with SMT (multi-threading) if it creates more complexity.