Often but not always.
For most newer FPGAs, routing is the main source of delay on the critical path, not logic. So if the synthesis tool lowers the logic depth, but does so in a way that increases the distance the signal must travel on the chip, it likely won't help FMax.
This can be caused by increased logic usage, if the synthesis tool must create significantly more LUTs to reduce the critical path. This may make it harder to place the logic on the critical path close together, increasing the routing delay.
Additionally, if the synthesis tool replaces something with a dedicated routing path (most FPGAs have dedicated routing for carries, some may have dedicated routing for local connections in a CLB or between CLBs). These dedicated routing connections usually have a lower delay than the general purpose routing network, potentially increasing delay
The figures they have listed look promising though, they're lower or comparable to the commercial tools in terms of resource usage, with lower or comparable logic depths. They do however not have support for things like carry chains, which may potentially make some things like adders slower than the other tools.
That is unlikely to work. Centrifugal separation works when the fluid you're trying to separate is a suspension of either solids or multiple fluids that do not mix (such as oil or another fat and water). Blood is a suspension of several types of several things (red and white blood cells, platelets, minor amounts of other stuff) in plasma, so you can separate each of those components out with a centrifuge. Soda, unless it contains something like fruit pulp or dairy, is generally not a suspension and therefore will not be separated by a centrifuge
> and replacing them with just straight up floating point calculation
Not only that, the diff replaces 100-150 lines of code with 3. That's the kind of pull request I can only dream of making
On gcc 13, the difference in assembly between the min(max()) version and std::clamp is eliminated when I add the -ffast-math flag. I suspect that the two implementations handle one of the arguments being NaN a bit differently.
x86 was designed/developed back when a lot of programs were written in assembly, so writing assembly for it isn't terrible especially if you focus on the simpler instructions. Things like accessing global variables or manipulating the stack tend to be easier on x86 than on a load/store architecture because of all the addressing modes available.
I personally would nominate POWER/PowerPC for Not The Ideal Assembly Language To Learn. Lots of confusing mnemonics, like two addressing modes, and registers identified by number instead of by name. It was not designed to be written by humans
The DRAM chips themselves are asynchronous (there's no clock signal connected to the RAM chip), however they expect a sequence of operations with specific timings in order to work. The PET's solution was to create a small synchronous circuit to generate the control signals with the correct timings for the DRAM. This however wasn't the only way it could be done, as the other answer states how the PC/XT did it with delay lines.
Well for one, not everyone is able to eat eggs or dairy. For these people (such as myself), there's not an alternative besides a plant based substitute. To me it's pretty exciting to see new developments here. People in this category probably aren't a large portion of their market though.
Generally yes. Sending morse is much easier than receiving it. Once you are comfortable receiving morse at 25wpm for example, the amount of practice needed to send at that speed is pretty minimal.
Logic Gate != Transistor and FPGA LUT != Logic Gate
FPGA LUTs are quite sophisticated, the LUTs in both Xilinx and Intel's latest offerings are able to implement an arbitrary boolean logic function with up to 6 inputs and 1 output. The FPGA also comes packed with other specialized hardware such as on chip memory and multipliers so you do not need to burn logic to use those things. You very likely could fit a Pentium III on a moderately large FPGA.
The real challenge would be matching the clock speed of the original processor. Even 400MHz of the first pentium IIIs on the market might be difficult, getting near 1GHz is likely impossible.
I am not sure if this generalizes to non-64 bit platforms, but in my experience using size_t gives you unsigned integer indexing without requiring overflow checks (as it's normally a 64 bit quantity).
This can be caused by increased logic usage, if the synthesis tool must create significantly more LUTs to reduce the critical path. This may make it harder to place the logic on the critical path close together, increasing the routing delay.
Additionally, if the synthesis tool replaces something with a dedicated routing path (most FPGAs have dedicated routing for carries, some may have dedicated routing for local connections in a CLB or between CLBs). These dedicated routing connections usually have a lower delay than the general purpose routing network, potentially increasing delay
The figures they have listed look promising though, they're lower or comparable to the commercial tools in terms of resource usage, with lower or comparable logic depths. They do however not have support for things like carry chains, which may potentially make some things like adders slower than the other tools.