3 ms·
Reading through all of that, they're saying that they avoid a jungle of ifdefs to support multiple similar architectures, and they say the way to this is "isomo
by DougMerritt 4y ago
Reading through all of that, they're saying that they avoid a jungle of ifdefs to support multiple similar architectures, and they say the way to this is "isomorphism", which is supposed to be the opposite of abstraction.
Ok I get the gist, but no examples; how do they achieve that? A different page gives a list of supported calls, which seems to make it clear that what they did was a (probably a good job of) factorization of the problem domain into a set of standardized library calls [1] that model the abilities of the entire set of architectures closely. Applications/games can then use that library without #ifdef'ing for different architectures and still get highly efficient results.
Very clever, but of course they don't claim that their approach generalizes to very different architectures, like say X11 on RISC-V or something.
[1] https://retroprogramming.iwashere.eu/midres_library:functions https://retroprogramming.iwashere.eu/midres_library:function...
- somat 4y agojust curious about your example X11 on riscv, if asked, my naive answer would have been X11 is mature, stable, well tested code and would run on risc-v without too much trouble
- DougMerritt 4y agoThe point is that their "isomorphic" graphics library generalizes over only the typical capabilities of early 1980s 8-bit systems with sprites etc. X11, Wayland etc have a thousand times as much capability. Their solution is possibly an elegant solution to their problem space, without the ability to generalize much further than that. As far as I can see from the material. In the link I gave, the names of the library functions, and shortness of that list, suggests that all by itself.