28 karma · joined January 20, 2022
To do it in almost-plain C, you'd need fairly complex macros that are more difficult to write correctly.
To do it in plain C without macros, or plain C++ without templates... you'd need to work out the combination of the template expansion yourself and write down a piece of code that is more likely to have bugs and more difficult to understand.
By making 3 instances of linear_feedback_shift_engine class template ( and 2 of xor_combine_engine ), you are forcing the compiler to expand the code exactly as-is 3 times, each with different parameters.
The parameters to the template are constant, therefore the compiler can easily look at how they are used and you are guaranteed ( even in a 1999 c++ compiler ) that the compiler will look at the copies of the code and merge them as much as possible into a single piece of code... which is the one that you see when you decompile the code.
So in summary, it means that you get to write fairly readable code while the final binary is fully optimized as-if you had spent the time merging all the variants as needed for the specific constants.
ps. Also used in the original circuits of the Yamaha DX7 synthetiser ( https://www.righto.com/2021/11/reverse-engineering-yamaha-dx... ).
We somehow got a copy of Defy diskmag, started swapping with Cro^Cydonia and got to enjoy Satisfaction Guaranteed by Pearl :)
I always did all my small tools and stuff in blitz basic 2, would dump binary file and incbin them in Devpac.
-- winden^TNC^Network
[ https://www.pouet.net/prod.php?which=14404 and https://www.pouet.net/prod.php?which=7645 ]
The actual problem is that mp3 decoding requires lots of math, and the total cpu usage to decode at 22Khz mono is the equivalent of a 68030 running at 50mhz, which is more or less 5 times as much CPU as a 68000 running at 16mhz.
Never sure why I did this association, maybe it comes from a drawing in a book I read when I was six or somthn?
move.b #200,d0
move.b #100,d1
add.b d0,d1 ; 8th bit goes to X flag
subx.b d0,d0 ; d0 = $00 or $ff depending on X flag
or.b d0,d1 ; d1 = 255 if there was saturation
You can do the same with all others that somehow store
the 8th bit carry somewhere then allow using it for substraction.Also this way of framing "As of February 2026, the US dollar has lost 96.9% of its purchasing power relative to January 1914. This means that $100 in 1914 would buy only approximately $3.05 worth of goods today" is of course math-correct but difficult to understand intuitively.
I think it makes more sense to explain it in the opposite direction or in both directions: "$100 in 1914 would buy only approximately $3.05 worth of goods today, or equivalently, $100 in 1914 is worth ~ $3278 nowdays (because 100 / 3.05 ~= 32.78 "
This also makes it easier to understand that the term "millionaire == person that has 1 million USD" only makes sense around 1914, because the equivalent amount of wealth nowdays would be "millionaire == person that has 32 million USD"
Anyways, I liked a lot this visualization https://mlde8o0xa4ew.i.optimole.com/cb:VNTn.d9a/w:auto/h:aut... that visualizes the compression in time of the big value changes.
https://linuxjedi.co.uk/2021/12/27/800mips-amiga-with-emu68-...
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_gui...
and more generally:
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_gui...
cf:
[1] http://www.gravisultrasound.com/files/documentation/GUSFAQ.t...
[2] http://bax.comlab.uni-rostock.de/dl/Paula_SystemTheoretic.pd...
so the traced calls would more or less be:
https://sources.debian.org/src/glibc/2.33-3/sysdeps/m68k/tls...
https://sources.debian.org/src/glibc/2.33-3/sysdeps/unix/sys...
Maybe it is all related to errno needing to read the base TLS pointer? https://sources.debian.org/src/linux/5.15.15-1/arch/m68k/ker...
Sounds like we'd benefit from placing the result of calling sys_get_thread_area(void) in the VDSO area and updating it from http://lxr.linux.no/linux+v5.14/arch/m68k/include/asm/entry.... every time we do a process switch
Could you get some kind of stack trace at the time of the get_thread_area call?
I'd like to be able to pinpoint the call(s) somewhere in
https://codesearch.debian.net/search?q=get_thread_area&perpk...