51–60 of 79 posts
It would be interesting to compare this project to simply converting 6502 assembly into LLVM IR, and letting clangs optimization passes work their magic. Obviously self modifying code would be hard to handle, but every other case ought to work, and the auto-vectorization ought to do amazing things to some loop-heavy code.
It would be interesting to compare this project to simply converting 6502 assembly into LLVM IR, and letting clangs optimization passes work their magic. Obviously self modifying code would be hard to handle, but every other case ought to work, and the auto-vectorization ought to do amazing things to some loop-heavy code.
Is this what you're (roughly) referring to?: https://andrewkelley.me/post/jamulator.html Although the programmer's target is an entire system, the conclusion may still apply: > There is a constant struggle between correctness and optimized code. Nearly all > optimizations must be tossed out the window in the interest of correctness
Earlier quoted context omitted.
I understand that some people look suspiciously at the 15GHz mark, specially considering this was run in a 4.5GHz processor. What I understand is that this benchmarks are comparing how long it would've taken on a stock 1Mhz 6502, and calculate the "clock speed" obtained as a ratio. So if I'm getting my result 10,000 times faster than a standard 6502, it means I'm at 10GHz. I also understand that this is possible beca…
I like the framing here, that of seeing this as a showcase of modern superscalar improvements. And yes, it's about single core performance only. What is particularly interesting to me is how thoroughly superscalar "wins". Because of complexities with 6502 -> x64 mapping, and handling self-modifying code in particular, some of the most common 6502 instructions explode to multiple x64 instructions. Despite that huge ex…
Earlier quoted context omitted.
18 MHz, actually -- the FPGA clock speed is 73 MHz, but it executes the equivalent of one 6502 clock cycle in four of its clocks. That being said, this was implemented on a budget-line FPGA from 2006 (XC3S50A - a small Xilinx Spartan-3A). A modern performance-line FPGA would probably hit a couple hundred MHz easily.
It's still surprising how little relatively to the level of perceived performance have IPC count improved since seventies.
Huh... I hadn't considered it before, but Bender's brain could actually be a 6502, just being run at an insanely high clock speed. A few petahertz should be able to handle the AI involved, no? Planck time is like 10^-43 seconds, so there's lots of room to divvy up a second for more processing power given advanced technologies...
Earlier quoted context omitted.
"until pins stop wiggling"?
The pins don't physically wiggle. "pins wiggling" is a common metaphor for "the voltage level on a pin is changing". As a signal driver is toggled at increasing frequencies ('cranking up the clock'), the signal amplitude (voltage difference between the 'high' and 'low' period) starts to drop. At a high enough frequency, the signal will be indistinguishable from noise and 'stops wiggling'.
Scopes lock at first rising edge after last horizontal scan, so display starts at H, then drops to L after how long CPU held that pin high. That creates ￣￣l＿ lines on the screen superimposed to one another, X position “wiggling” ￣lll＿ depending on how many consecutive H bits just happened to be sent.
When the CPU halts, the pin would flatline at H or L and you’ll know.
Earlier quoted context omitted.
The perceived performance for an average desktop has been pretty stagnant since, I don't know, at least the mid-nineties.
Softare expands to fill the CPU available.
Earlier quoted context omitted.
It's still surprising how little relatively to the level of perceived performance have IPC count improved since seventies.
The perceived performance for an average desktop has been pretty stagnant since, I don't know, at least the mid-nineties.