Was Terry A Davis right? (TempleOS)

A

anon

Guest
#21
I tried to build an OS when I was 13, successfully booted and displayed the bitmapped keyboard input, then I realized I could only utilize a small section of the x86 instruction set, it would take FOREVER to learn them all, so the OS would be slow by default.
As Terry said:
Your f🅰️king SSE MMX is garbage I have no use for that 💩, it is a complete clusterf🅰️k, I am not even going to support it
 
Apr 8, 2018
391
1
18
#22
As Terry said:
Your f🅰️king SSE MMX is garbage I have no use for that 💩, it is a complete clusterf🅰️k, I am not even going to support it
Listen
I've developed a few Apps
SSE MMX work fabulaously, sometimes you need SSE3 or AVX2 and tune the compiler to run a profile on the programs and compile optimally in O3 and it is fast as f🅰️k. We're talking about vectorising programs to finish many instructions in ONE cycle. If you try to do that with higher clock speed we would be talking about 20+Ghz, and that is just impossible with silicon at room temperature.
 
Last edited:
Apr 8, 2018
391
1
18
#23
Maybe when the Gallium Nitrite (GaN) or some crazy computers comes out we can redesign the whole architecture, but right now with silicon, more instruction set is better.

My vision is more instruction set per core, more cores, more cache for servers, and for desktops, they should be ASIC thin clients connecting to the server farm using infiniband fiber running encrypted computing.
 
Last edited:
Mar 31, 2018
662
3
18
#25
My vision is the new CPU is like a FPGA, the compiler breaks down the idiot high abstraction code and finds out what can be implemented by hard logic and what can be done with ASIC, then it generates custom ASICs and hard logics to be run on the FPGA, combing hard logic and ASIC to achieve insane computational powers. But this requires insanely fast re-routing of FPGAs, not possible right now

Another idea is to use silicon ASIC cartridges that contains and runs the application, only exposing the APIs, when you need the application, you plug it into the computer. This runs fast and eliminates software pirating.
 
Last edited:
Apr 8, 2018
391
1
18
#26
My vision is the new CPU is like a FPGA, the compiler breaks down the idiot high abstraction code and finds out what can be implemented by hard logic and what can be done with ASIC, then it generates custom ASICs and hard logics to be run on the FPGA, combing hard logic and ASIC to achieve insane computational powers. But this requires insanely fast re-routing of FPGAs, not possible right now
You know how BIG the die would have to be just to run a 200k line Verilog, that your compiler just pooped out?
It's better to use FPGAs as additional modules, oh wait they already have that on AWS and Azure.
 
Mar 31, 2018
662
3
18
#27
You know how BIG the die would have to be just to run a 200k line Verilog, that your compiler just pooped out?
If you boil down the logic of a program, the computationally intensive parts are normally two
  1. CPU bound, often repetitive, math heavy and easily vectorized, good for FPGA,
  2. IO bound tasks, there isn't a better fit for FPGA,
gluing and interfacing are often not demanding but logically complex, it will occupy too many cells, but is ok to put them in ASICs as regular programs. So I don't think the overall die will be that big.

I actually played around with Xilinx Zynq processors, the FPGA + coprocessor chip is really fast but just not very versatile, I think it's totally doable. If terry wrote an ARM version I would be running TempleOS on Zynq.