>mfw machine code is just an interpreted language.
>mfw a CPU is just a silicon interpreter.
>>54893053
good shitpost
>>54893276
It's true, faggot. Interpreters take programs and run them, producing a result.
>>54893053
> mfw it took you any amount of time to realize this
>>54893053
It's JIT'd to microcode and you could even say that register renaming makes it a stack-machine like the JVM :>
>>54893403
>microcode
Wait, are you fucking kidding me? You can go lower level than machine code?
>>54893053
Babbys first philosophical revelation.
Cute
>>54893437
>philosophical
Damn, I didn't know actual mentally retarded people use this site
>>54893426
Than assembly? Yes. Well, the manufacturer can, you can't.
>>54893053
>Wait, are you fucking kidding me? You can go lower level than machine code?
Depends on the architecture. Microcode is a hallmark of CISC. RISC and the various pure architectures like R-machine, S-machine etc, don't use microcode.
The microcode in modern processors like Core isn't truly microcode in the classical sense; it's more like programmable internal controller state.
>>54893566
I don't get it. I thought machine code instructions ran directly on the CPU. Why does it need to be compiled again?
>>54893590
>Why does it need to be compiled again?
It's not compiled again.
Just think of it as firmware.
>>54893053
later Kevin.
>>54893618
>firmware is not instructions
what?
>>54893426
On a CISC architecture (x86 for example) ISA level instructions are themselves implemented through even smaller steps. These smaller steps exist in something called the microstore / MPU, which is what actually directly controls the hardware by placing bit patterns onto a control block (which brings physical lines high or low). For instance, you may use the ISA level mnemonic ADD, but the microcode is responsible for actually putting those values in the ALU registers, executing the correct ALU function, and putting the result in the destination location.
>>54893709
Architectures like Itanium left all that lowlevel microp scheduling and arrangement up to the compiler, and it was a massive clusterfuck.
>>54893709
Okay, I see. So it is JIT
Is there any reference for this stuff? Like, what if I wanted to know what the CPU did with my ADD command? Or what if I wanted to know the algorithm the ALU used?
>>54893658
there is assembly code which was originally run directly by cpus, manufacturers wanted to introduce improvememts to the architecture so they changed the processing unit and added a "hardware translator" from assambly to microcode. It's much more complicated than this, but you get the idea
The goat's troubles are over now.
>>54893754
>there is assembly code which was originally run directly by cpus
Not always. Even the earliest CPUs ran microcode. Look at the giant op decode blocks in the 4004, 8008, 6502, etc... takes up a full third of the chip.
>>54893751
>So it is JIT
Not really.
>Is there any reference for this stuff?
Yes, here's my reference text. The topic is called Computer Organization.
> if I wanted to know what the CPU did with my ADD command? Or what if I wanted to know the algorithm the ALU used?
Look up your processor's specs book. Past that, you don't get to know; those are "trade secrets". You could always implement your own processor in a logic simulator though, then you'd get to write your own micro code.
>>54893751
>Is there any reference for this stuff?
The one I like is Computation Structures. If you follow it all the way through, it will take you trough building several architectures using 74LS logic.
>>54893785
The whole idea that made RISC different (back in the day) was that if you had a much simpler opset, you could run it directly on gates instead of having the intermediate layer of microcode. Pretty much everything had microcode up to that point.
>>54893806
>>So it is JIT
>Not really.
Of course it is, the raw instructions get decoded into µ-ops and cached for later use. On Sandy bridge and above (IIRC) µ-ops get even more optimized when running by fusing some together and dispatching them simultaneously. It's like magic.
If you're interested in the gory details and some history:
http://www.agner.org/optimize/microarchitecture.pdf
>>54893910
>On Sandy bridge and above (IIRC) µ-ops get even more optimized when running by fusing some together and dispatching them simultaneously. It's like magic.
And this is why RISC will never win.
>>54893751
Reference for actually inside the CPU itself? Sometimes they post information about the specific architectures but almost all of the actual deep µop stuff is under NDA.
>>54894134
On the contrary, RISC kind of half did win - every single x86 chip since the Pentium Pro has been essentially hybrid with a kind of JIT translator, albeit in a very simplified, hardware-optimised form. (Notably, the Transmeta Crusoe exposed its internal RISC cores and its hypervisor directly.)
A really good optimising compiler with lookaheads and superoptimisation passes can always beat a JIT under hardware and gate constraints - hell, the VLIW thing the Itanium was rocking was trying to bypass the whole shebang by getting the compiler to do all its pipelining! Unfortunately that was decades before compiler tech was good enough.
Good RISC does pretty damn well, especially if the instruction encoding is compact (cache efficiency) and simple (low-delay decoding pipeline). I do feel RISC-V has a very strong, and very fast, future ahead of it.
>>54894134
>And this is why RISC will never win.
Purity for purity's sake never wins.
>>54894134
It's also why AMD will never win.
>>54893053
What a waste of bullets. Just chop it's head off
I think binary is the lowest you can go but good luck writing anything in that.
>>54893317
Yes, but by your strict definition the term is simply useless, since it does no discrimination.
"Interpreter" usually means "software interpreter", which makes the term useful.
>>54893785
A decode PLA is a different thing from microcode, though.
>>54893709
You are describing hardware control lines, which is not the same thing as microcode.
>>54893751
Agner Fog's microarchitecture guide is a pretty good document:
http://www.agner.org/optimize/microarchitecture.pdf
>>54894134
>everything in the world not weighed down by x86 backwards compatibility issues is RISC
>"And this is why RISC will never win."
How's that 5% improvement from Intel's latest WhateverLake architecture anon?
>>54895522
Better than using a 10 year old EV7. Or a Cortex A-72, for that matter.
>>54894997
People have actually written stuff in binary. In fact, assembly was originally not something you actually put into a computer, it was an intermediate organizational step that you wrote and then looked up the binary opcodes which were what you put into the computer. And it's actually more space-efficient than even assembly (though optimizing assemblers might have this benefit as well), since if your program requires adding a number, say 103, to a register, and your program happens to include an instruction elsewhere whose opcode + arguments happens to be the binary representation of 103, you can use the address of that instruction as an argument to the add-to-register instruction, rather than having to put 103 in some other memory address.
then why can't we convert javascript to binary and compile it?
>>54895904
https://webassembly.github.io/
>>54895921
>assembly
what part of my post didn't your dumb ass understand?
>>54893053
Outside of computer science, the word interpreter generally refers to someone who does oral translation between different natural languages. For example, if John who only knows English wants to interview Hans who only speaks German, they would need to have an interpreter who speaks both English and German. Interpreters in computer science are similar, they convert between different languages. The only language a CPU can understand is binary machine code, so the interpreter must convert some language, like Javascript, BASIC, or Python into machine code. That conversion is what "interpretation" refers to. But running a precompiled binary doesn't really involve any conversion, the binary is already in machine code. It's more like public speaking, or reading a book.
>>54895904
>>54895967
http://javascript-exe.com/
Although it's arguably not a "real" binary, since it actually creates JVM bytecode rather than native machine code. But still, JVM bytecode is a form of binary instructions.
>>54895967
Web assembly is essentially ahead of time compilation. It saves the web browser from having to use JIT compilation so it's basically equivalent to compiled javascript but it's not a straight up binary that can be run directly on the hardware.
>>54893806
So its not foss? That must be troubling for stallman
>>54895967
Which part of the page did your dumb ass not read?
>>54895071
You misread my post. The microcode controls the hardware control lines.
>>54896025
That's why he uses a Leemote.
>the raw instructions get decoded into µ-ops and cached for later use
Again, not really. Once assembled the machine code essentially addresses the microstore (for the micro program counter). Each instruction addresses 1 location in the MS, which will run a microprogram.
>>54896041
fight me irl
>>54896384
>uses a Leemote
used*
His leemote got stolen by a mexican or some shit. Now he uses a thinkpad running libreboot
>>54893566
There have been CPU's with writable microstore. I once (1991) worked on a lisp compiler for a writable microstore CPU from Harris Semiconductor. It had a base set of instructions in ROM microstore, and the rest were in SRAM. The basic instruction set was sufficient to support a language like C so you do useful work with the base instruction set, and it also obviously had instructions for manipulating the microstore.
The guy that designed it was interested in lazy functional languages, so he had an instruction set for doing graph reduction. My instruction set had support for tagged data and non-pausing GC.
Fun times. We just don't see interesting CPU's anymore, maybe the Mill if it ever tapes out. But that's about it.
>>54895904
Because it relies heavily on dynamic lookups and dispatches, which often largely negates the benefits.
>>54896384
>You misread my post. The microcode controls the hardware control lines.
Yes, but they can be, and often are, controlled without microcode.
I love how I will never understand how CPUs work but I'm in awe as to how far we've come so quick and how were just throwing these fuckers with millions amd billions of transistors into everything.
>>54896686
Ra's will soon change that. Everything is super sensitive to EMP now.
>>54896686
If you feel like it you can watch this video and feel even more awestruck
https://www.youtube.com/watch?v=eDmv0sDB1Ak
A presentation by an engineer from AMD
>>54896728
>Ra's
Que?
>>54896773
>no poo in loo accent
Pleasant surprise
>>54894955
No ahmed, they're obviously not in a desert. We don't do that in the civilized world.
>>54897669
>killing
>civilized
>>54897701
It's not civilized, but it's perfectly natural.
>>54897701
#Justice4Harambe
>>54896540
You have interesting experience, anon. Thanks for posting on /g/.
>>54893751
Just go to opencores.org and read some CPU sources.
And download "computer architecture: a quantative approach" from libhen.io , it us a standard textbook on this subject
>>54896540
The Xerox Alto workstation also had a writable microstore. It had different instruction sets for BCPL, Smalltalk, Interlisp, and Cedar/Mesa. One of the (many) interesting things about it was the microcode engine could run multiple microcode threads cooperatively.
Pic related, it's an Alto.
>>54893053
What are the cons of a RISC architecture compare to a CISC one? I only know of the benefit that RISC has over CISC is that everything is much simpler because the instruction sizes are all the same.
>>54898652
Lower instruction density means it stresses the memory system more - modern CPUs are basically I/O bound. Also RISC CPUs originally achieved their simplicity by offloading pipeline scheduling to the compiler. But this meant that when the next generation designs came out they had the choice of not running software that had been compiled for the previous generation, or retaining compatability by adding circuitry to fix up the scheduling. They generally opted for the latter, meaning they lost much of their advantage over CISC at the same time as Intel was busily converting the core of their x86 architecture to RISC. Nowadays the teo philosophies are more similar than different, once they went superscalar they all wound up with extremely complex designs. The instruction set architecture is the main difference, behind the scenes they all convert to micro-ops and schedule those internally, with register renaming and store forwarding and all the complexity.
RISC 8-core POWER7+ had 2.1 billion transistors, CISC 8-core Xeon Nehalem had 2.3 billion transistors. Similar timeframe (2010), similar market (server). CISC design was faster, cheaper, amd used less power.
The Mill architecture is an attempt to regain some of the simplicity while retaining performance - it exposes its architecture in a different way than RISC, and requires software jitting of all programs to the physical architecture in order to run, but it'll be awhile before we find out if its advantages are real or theoretical.
>>54899110
>requires software jitting of all programs
Sounds like yet another Transmeta, then.
>mfw you are just quarks interacting with one another
>>54899416
No, it's much simpler than that because the src and dst ISAs are very similar. The jit compilation step is simple enough that the jit compiler is created programmatically by the design software. It's simple enough that jitting is done by the loader, it doesn't happen on the fly like transmeta. It just adjusts the instructions to match the scheduling and resource constraints of the physical machine vs the idealized machine, and the Mill architecture makes this very easy. It's not a conventional architecture, there are no registers or stacks, just something called the Mill (hence the clever name).
>>54899585
I meant similar in the way that it tries to offload dynamic scheduling to a JIT, which I won't trust any further than the number of cache levels I can throw a load or store.
>>54899691
No, it offloads static scheduling to the jit (pipeline stages, # of execution units, etc). Dynamic scheduling is still managed by the cpu, but its a much simpler task than on a register machine. The architecture eliminates many of the dependencies and hazards in a register architecture, allowing compilers to statically schedule very high levels of concurrent dispatch. One of their examples on a fairly real world piece of code had something like 18 instructions in flight at once - all scheduled statically by the compiler. The physical machine may only have 4 execution units so the jitter has to adjust the code to match the real hardware. But memory stalls are handled dynamically by the hardware, not by software. But the register renaming, translation to micro ops and micro op scheduling, and most OOO issues are absent..
>>54900144
It seems difficult to actually find any real technical details about the architecture, but it's difficult to see how you'd handle variable-latency operations efficiently without dataflow scheduling.
>>54900339
There's probably a reason why it still doesn't exist, 13 years later.
>>54893053
>the scheme-79 chip was invented over 30 years ago
>we could have a hardware garbage collector, and a sane "high-level" language for OS and kernel development this whole time
>>54900339
It's a dataflow architecture, so a lot of information that is lost when compiling to register architectures are retained in Mill programs. Basic blocks are surfaced in the Mill ISA, for example. You're right that low level technical details are hard to come by, the videos of their presentations at stanford and google are pretty good, but they're being cagey partly because of patents and partly I suspect because they may not have figured out everything yet. Still, it's an interesting set of ideas. We won't know how well it really works until they have production silicon.
>>54900567
The Burroughs large systems had that since 1961, and in fact had an operating system implemented entirely in a high-level language.
There's a reason it went out of business.
>>54893053
how far down the rabbit hole do we go?
>>54893326
you didn't post a face idiot
>>54901085
Psssh… Nothin Personnel… Kid…
>>54893426
>Wait, are you fucking kidding me? You can go lower level than machine code?
yes, it's called a circuit
>>54900576
I just watched his talk at https://www.youtube.com/watch?v=QGw-cy0ylCc and it was all about static scheduling of fixed-latency operations. Do you have some resource where they speak about variable latencies?
>>54901115
That's not code. Software is mutable, circuits aren't.
>>54901268
Microcode isn't really mutable either.
>inb4 patchable control store
You patch it at most once per power-on in the vast majority of cases.
>>54901317
It's pretty obvious that microcode is software while circuits are hardware
>>54901394
Au contraire, it is arguably just a specific implementation of trace routing.
>>54901241
Also, in response to >>54899585 the source and destination ISAs don't seem similar at all. The video describes a very wide VLIW, which seems about as far from x86 as you can come.
