RANT : Why do Many Not Consider Simplicity

All opinions on this site are those of the author alone.
No warranty of any kind is provided.   All information herein is provided as is without any warranty of any kind.


Why do Many Not Consider Simplicity :

Sometimes things move forward in ways that do not consider what is already known to work well. Sometimes things do this at there own loss.

An example being when ARM went to a Harvard cache (separate Data and Instruction caches), when most Operating Systems on the ARM used the comment field fo the SWI instruction to specify the system call. It would have been a simple matter to add a register to the system coprocessor (cp15, built into most ARM CPUs) to hold the most recent SWI instruction, thus negating the problems of contaminating data cache with code. Yet they did not, instead they went with the known slow down from having to separately fetch the instruction into the Data Cache.

There are many more examples of this kind of thing, including some that would have had ARM, MIPS, and 68K systems running up to 4 instructions per clock in an easy to optimize for manner, and have the timing remain predictable, all in the mid 1990s. This is a pet peve of mine, as I knew of the method of multiple issue implementation that could have done this with fewer transistors than were common before the mid 1990s, and no one did it in a commercial design.

The examples go so many directions, including many areas of software as well as hardware. If consideration were taken to how to best do something we would be a lot better off today. This goes for everything from the CPU to the OS, to the Calculator in your Desktop Environment.



This site hosted by NEOCITIES
© 2022 David Cagle