How CPUs are Designed and Built: Fundamentals of Computer Architecture

meric

TS Maniac
Today, CPUs are designed and produced in tandem with a co-processor called "Intel Management Engine" of which we have not much idea what it does (other than the very small explanation intel gives). This IME has its own platform and runs its own OS called minix. It runs irrespective to your main OS, completely hidden and has access to your LAN, HDD, RAM and pretty much anything on your system. It can run even when your PC is shout down.
 
  • Like
Reactions: regiq

ThomasTECH

TS Rookie
Great read, nice to find such a transparent analysis of the PC architecture. I have been advocating for the 16gb cache memory but lacked the understanding of why it was better beyond the 'it's faster processing' summary. Now I can go into detail about how that faster processing is achieved!
 

gkovacs

TS Rookie
The illustration showcasing the difference between 32-bit and 64-bit memory addressing is misleading when claiming more than double of addressable memory. 64-bit address space provides 2^32 times the addressable memory of 32-bit addressing, so displaying "8+ GB" is super wrong.

"In principle, a 64-bit microprocessor can address 16 EiBs (16 × 10246 = 264 = 18,446,744,073,709,551,616 bytes, or about 18.4 exabytes) of memory."
https://en.wikipedia.org/wiki/64-bit_computing
 
Last edited:

mbk34

TS Member
Interesting article. Takes me back to my first computer which could only be programmed in machine code, it didn't even have assembly language! Your diagram of the levels of language (high level, assembly and machine code) is probably a little too simple to represent the entire truth. Assembly is just a human readable version of the computers machine code. Also, very few languages other than C are compiled directly to assembly/machine code. Of the 3 languages you mention, Python is usually interpreted rather than compiled and Java gets turned into an intermediate language which is then interpreted.

Compilers don't output assembly or machine code directly because it just gets too complex to cope with all the different processors out there. Instead they output an intermediate language (Zend, C etc) and then let the local C compiler turn it into the specific code for that processor. Java with it's JIT compiler (just in time) is slightly different in that it compiles into an intermediate language which is interpreted but chunks of that code can then be properly compiled if those bits need to run faster.

There's also another lower layer called microcode which controls how the processor runs the machine code. There was recently an Intel release of new microcode to protect us against MDS vulnerabilities.

I tried rewriting this a few times to make it understandable. I suspect I failed :(
 

Raytrace3D

TS Addict
This was a great article. Made me whip out my old Upgrading And Repairing PCs 5th Edition (from the mid-90's). :-D Really enjoyed this article and look forward to the next.
 
When I see articles like this I always think back to the early pioneers of programmable computers.

I honestly think even the likes of Zuse, Turing, Mauchly and Eckert would be mind blown by how far we have come in such a short space of time.
Not sure I'd agree with that statement - I've been doing hardware and software at the cutting edge for over 50-years and not much discussed here is new - it is just faster and implemented in a far more efficient fashion. But, "way back then", while designing OS and hardware for 8-bit lab computers we were working the same issues as presented here. I was teaching classes about memory hierarchy and relative speeds and the cost of those differentials more than 40-years ago.

The current implementation of the hardware and software described is fantastic and I, in 1975 while working on a state of the art process control computer, refused to believe an IBM engineer who described a "thumbnail sized CPU." But, we did know that hierarchies, pipelines, speculation were critical issues. Thirty five years ago I refused to believe we could have I/O pipes wide enough or quick enough to support ARPANET connections for real time data acquisition but we sure did know the need for it.

Today's hardware and software are fantastically clever and spectacularly implemented - but they solve problems that were identified a very long time ago.