mbitsnbites

12 ms·

61.
by mbitsnbites 3y ago
For loads you can usually hide the clobbering by using the intended target register (the one you want to load to) as the temporary register, so e.g: // a0 = load [a1 + a2*4] slli a0,a2,2 add a0,a0,a1
62.
by mbitsnbites 3y ago
An MMU is somewhere on the TODO list. I'm still focusing on user space and I still have not added support for interrupts or exceptions. Exceptions in particular is something that I want to research more before I dive into implementatio
63.
by mbitsnbites 3y ago
So the demo is actually running on a DE0-CV, with a Cyclone V. A key thing for running Quake at acceptable speeds is to have a proper FPU, and most hobby softcores tend to exclude those. I actually expect the CPU to run even faster (same cl
64.
by mbitsnbites 3y ago
110 MHz
65.
by mbitsnbites 3y ago
Hi Bruce! :-) Well, to be fair I said "inspired by", not "copied from". BTW, I'm not trying to bash RISC-V (although it may come across that way sometimes).
66.
by mbitsnbites 3y ago
> the addressing modes I like having aren't there, so I made an ISA with them Not really... Se my other comment: https://news.ycombinator.com/item?id=39042048 I'm not alone. Many others with far more experience
67.
by mbitsnbites 3y ago
The RISC-V authors rely heavily on the argument and assumption that any high performance implementation will do instruction fusion , and the lack of indexed addressing is precisely one of the things that is expected to be fused (see page 6
68.
by mbitsnbites 3y ago
Yup. Latest and greatest GCC 14: https://gitlab.com/mrisc32/mrisc32-gnu-toolchain
69.
by mbitsnbites 3y ago
Yes. I run Quake at 320x180 (16:9), but the VGA signal is 1920x1080, so the video HW scales the framebuffer using nearest neighbor interpolation, and then it's all displayed on a super-crisp modern monitor. So the pixels are very sharp
70.
by mbitsnbites 3y ago
It would be much simpler to just put the FuryGPU and the MRISC32 CPU on the same FPGA, I guess.
71.
by mbitsnbites 3y ago
I'm really impressed by your work! I'd love to see more details (like the code ;-) ) in the future. Perhaps meaningless, but a cool demo would be the FuryGPU being driven by an MRISC32 CPU. Everything custom FTW.
72.
by mbitsnbites 3y ago
You can visit https://reddit.com/r/fpga There are lots of discussions about learning and getting hobby boards.
73.
by mbitsnbites 3y ago
Turns out that they were a good fit for the kind of rasterization loops that you find in Quake and Doom. E.g. https://gitlab.com/mbitsnbites/mc1-quake/-/blob/feature/port... They were also really si
74.
by mbitsnbites 3y ago
Haha! Infinitely far away (not on my horizon). Thought has crossed my mind, but there are so many other things I want to do first (e.g. audio, superscalar CPU, ...).
75.
by mbitsnbites 3y ago
The things you do in order to play Quake ;-) (BTW, recently started eyeing Quake 2 - but will have to work more on the CPU performance first)
76.
by mbitsnbites 3y ago
Realistically: No that won't happen (sorry to disappoint you). There are some niche demos, like a HW raytracer on an FPGA, but full systems is not realistic. General purpose code simply is a bad match for FPGAs.
77.
by mbitsnbites 3y ago
So I realize that the title is slightly misleading. It's obviously not a pure hardware implementation of Quake, but rather the original Quake software renderer running on a custom soft processor in an FPGA. I like to use it as a benchm
78.
by mbitsnbites 3y ago
There are efforts to bring FOSS FPGA tooling. Check out Yosys (still far from as mature as LLVM though). But yes, I agree...
79.
by mbitsnbites 3y ago
That would be closing the circle. Back in the 1970's some video games were more or less purely implemented in hardware (e.g. I believe Pong was originally implemented with discrete TTL chips, and a later hone version was implemented in
80.
Quake on an FPGA (MRISC32 CPU) [video](vimeo.com)
113 points by mbitsnbites 3y ago|104 comments
81.
by mbitsnbites 4y ago
I think that there's a real risk that "information becomes useless" in the AI era. Neither text, speach/sound, images nor videos can be trusted, and it's far toi easy and rewarding for unscrupulous actors to use AI
82.
by mbitsnbites 4y ago
The article has been updated with -O2 numbers. Spoiler alert: ARM & RISC-V still win over x86 & z/Arch.
83.
by mbitsnbites 4y ago
I believe that ARM has a patent on a workaround. Apple M1 has 192KB L1I.
84.
by mbitsnbites 4y ago
My experience from Thumb was that it makes code slower. Probably because the CPU had to execute more insteuctions than in "ARM" mode. Thumb was a thing for embedded systems with very limited RAM etc. It was not designed for optima
85.
by mbitsnbites 4y ago
It wouldn't matter. I still would not buy an i386, compile my programs in 32-bit mode instead of 64-bit, nor use the i386 ISA as a model when designing a new ISA. Same thing with 6502, Z80, Vax, etc. What matters is performance, and i3
86.
by mbitsnbites 4y ago
The results mean what they mean: If you compile your software with GCC -O3 you will typically get smaller code and fewer instructions on average for modern fixed size RISC ISAs than for modern CISC ISAs. You would have to do further and o
87.
by mbitsnbites 4y ago
1) i386 is not representative of bleeding edge CPU architectures (as mentioned in the article). It would only be icluded for purely academic reasons - which was out of scope. 2) ... 3) In the real world most programs use a single optimizati
88.
by mbitsnbites 4y ago
I just don't see how I would run profiling counters on a z15 machine for instance ;-) With my limited resources this got me much more architecture coverage. And as usual, the answers are in the data, it's merely a matter of what q
89.
by mbitsnbites 4y ago
Code density is not all about instruction length. It's also about instruction count . With shorter instructions you usually need to use more instructions to do the same thing (e.g. extra MOVs or stack spill etc).
90.
by mbitsnbites 4y ago
The 32-bit operands are actually hurting code density most of the time. An instruction that would take 4 bytes in a RISC ISA takes at least 5 bytes in a CISC ISA. Same thing with the 32-bit offsets for x86_64 conditional branches. Edit: W

More ›