See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.
Tuesday, February 22, 2022
This is a special case of "stupid nonhuman friendly names considered harmful".
RISC-V, like any instruction set, as extension. The extensions need names. The current standard names are stupid and human unfriendly.
For example, I just now see email that talks about "working through the process to move Svnapot aka the former Zsn to public review". I am the guy who originated the RISC-V NAPOT proposal for large pages. *I* had to do a double take to parse Svnapot - but at least "NAPOT" appeared in there somewhere, after I mentally parsed Svanapot into S.v.napot, where S = system, v = virtual memory, ...
The earlier name Zsn, I could never remember - and, again, I contributed the term NAPOT to the virtual memory discussion.
Stupidly short and obscure names had friction. They waste mind share.
other RISC-V extension names include
Some of these you can guess about what they apply to.
Ag comment: have verbose and compact names
Z-atomic-memory-operations ==> Zam
and so on
Did I mention that 1 of the reasons given for short obscure extension names was that they needed to fit within 8 or whatever characters on the command line processor for compiler?
Two different styles of getting work done:
When I started as a professional programmer, e.g. writing C code for PC hardware, one of my "superpowers" was that I might find a hardware manual for a device, e.g. a UART, and I would write a fairly complete implementation, e.g. a header file that had #defines for all of the encodings used write control registers that device.
I.e. I did it all upfront. actually not all, but I did a lot upfront.
This served several purposes
- it was a good way for me to study the device, hardware, software interface that I was using
- compared to only implementing what I needed at the moment, it meant that when I realized I needed something else I usually did not have to stop to look at the manual. I could usually just pick the typical name that I would use out of midair and coded and it would work
- completely decoding so that you can provide a full disassembly of all instruction
- but not necessarily implementing them, if the implementation is too complicated
- I start by googling for keyboard shortcuts for the application in question. when I find them, it is usually a fairly simple set of text edits to convert them into a primitive command set.
- I start using things, and over time I observed the need for new commands
- One of the key things to record commands that I want to say but which are errors
- When I would like to have a speech command to do something that is currently on a menu tree
- I will typically take screenshots of menu tree, and device commands appropriate to each of the leaves
- e.g. I said "... insert line...." and there was no insert line command
- so I had to navigate through the menus " drawing > shapes > use arrow keys to select the graphic line shape"
- I'm really glad that I'm using speech recognition. It is very much helping my computeritis pain.
- But I sometimes despair every time I need to write a whole new set of commands
- I would like to accelerate the process.