Hacker Newsnew | past | comments | ask | show | jobs | submit | lprib's commentslogin

It's probably hand written but they didn't reverse engineer the purpose of each wire, only the netlist. Some of them are labeled, eg `irdbus_normal`.


Sure it would probably be cheaper to chuck a cortex-A* or similar mid-range MCU in there. One advantage of FPGAs that it can achieve "perfect" emulation of a Z80 (or other) since it's running on the logic gate level. No software task latency, no extra sound buffering, etc. It can re-create the original clock-per-clock.


It's impressive as well


Using `unreachable()` instead of `assert()` for your preconditions without profiling first is just pre-loading the gun to shoot yourself in the foot in the future. When those preconditions are inevitably violated at some point, you will get random UB corruption rather than simply aborting as is the case for assert.


Yep, undefined behavior is unsafe, C in general is unsafe. There are plenty of languages that are safe, though a little bit rusty like ADA, use one of these if you want safe code.

If you still want to use C, for example for compatibility reasons and want to make it safer, assert isn't going away (unless you set NDEBUG). Preconditions are not "inevitably violated", there are ways of making sure they aren't, and I think an explicit "unreachable()" can help tools that are designed for that purpose.

Should you profile first before using unreachable() for optimization purposes? Maybe, but the important part is that now, you have a way of clearly and effectively tell the compiler what you know will never happen so that it can optimize accordingly, whether it is before or after profiling.

Compilers usually do a great job at optimization, but there are often some edge cases the compiler have to take into account in order to generate code that complies with the C standard, and it can have an impact on performance. unreachable() is one way to tell the compiler "please forget about the edge case, I know it won't happen anyways", the best part is that it is explicit, no obscure tricks here.

Side note about profilers: no matter what your strategy is with regards to optimization, I think profilers are essential tools that don't get enough attention. People talk a lot about linting, coverage and unit tests, but profilers are not to be left out. They are not just tools that tell you where not to optimize your code, they can also find bugs, mostly performance bugs, but not only.


> What would be the alternative

That's the point, there is not alternative at the moment. Breaking up monopolies allows competition and an alternative provider when something like this happens.


Gotcha, yes. Or a least regulate the said monopoly so they provide clear and open guidelines in regard to their policies.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: