Add files via upload

2026-08-05 15:18:51 +00:00 · 2016-11-10 19:53:58 -05:00
parent 3375c9ac01
commit c3b1ad015f
3 changed files with 220 additions and 0 deletions
@@ -0,0 +1,162 @@
 <html><head><link rel="stylesheet" href="style.css"></head><body><div class="page">
 <h1>20150509 - OS Project : 6 - Hashing</h1>
 <br>
 <i>Been a while since I had any time to work on this project.
 Renamed as I've done some major design changes...</i><br>
 <br>
 <b>Axed</b>
 <br>
 Dropping source-less programming part.
 Source-less worked great for x86 programming, 
 however there are a few things I didn't like about it.
 Little issues like having 2 words for each common forth construct 
 like "CALL WORD" instead of just "WORD".
 Larger issues being the requirement to have another editor 
 to generate complex data or non-x86 machine code.<br>
 <br>
 <b>From the Ashes</b>
 <br>
 Pulled the old work into a new bootloader.
 This time rapid prototyping using just NASM.
 Eventually I'll have to rewrite the bootloader 
 in the source/language I end up creating. 
 Switched back to 64-bit long mode (see why below).
 Running with 1GB pages since long mode forces page tables.<br>
 <br>
 <b>Re-Thinking The Forth Dictionary</b>
 <br>
 Time off from this project brought forth some new ideas
 addressing the original motivation for going source-less:
 (a.) don't like linear searches at interpreter-time 
 through large dictionaries (simple forth implementation),
 (b.) don't like how hashing (complex forth implementation) takes a bunch of ALU-time,
 (c.) really don't like how dynamic hashing can leave 75% of the cache unused,
 (d.) and still want to have full 32-bit values in source without multiple source tokens.
 <br><br>
 Solving (d.) is easy, just switch to 64-bit source tokens.
 Source is now 2x the size, but 32-bit immediates are trivial,
 and words can now use 10 characters instead of 5.
 Source is a prefetchable linear read,
 so the "more memory for more simple" trade is worth it to me.
 <br>
 <br>
 <b>Now Can Hashing be Made Better?</b>
 <br>
 Solving (b.): how about factoring everything in the hashing algorithm 
 except the "AND" operation 
 into the string encoding itself?
 The tokens encode strings as 60-bit integers.
 Just need to switch from a generic 6-bits per character,
 to something where the characters are encoded in a way that they effect all bits.<br>
 <br>
 One thing I tried is to use a reversible cellular automata (CA) like Wolfram Rule 30R.
 So strings in tokens are kept in memory in the form 
 after being processed through N steps of applying the CA.
 Editor to display the string simply has to reverse the CA process.<br>
 <br>
 To test the theory I first grabbed an english dictionary,
 then hashed to {256, 512, 1K, 2K, ... 512K, 1 M} entry tables,
 and tracked the {min,max,average} table bin counts.
 Comparing the reversible CA to just the 64-bit finalizer in MurmurHash3
 (not reversible but provides a good baseline): 
 both have similar results.<br>
 <br>
 Also tested against a dictionary with all possible {1,2,3} character strings
 (including symbols and numbers). Results are again similar.<br>
 <br>
 Second I tried a recursive interval encoding:
 each character is encoded in the interval of the parent character.
 First character starts with the full 0 to 2^60-1 interval.
 Character 63 is a special terminal character
 (signals no more characters are encoded).
 Character 63 gets a smaller interval,
 allowing the other characters to get an extended interval 
 designed to spread out the value  
 when ANDed to a power of two.
 This works similar in theory to arithmetic encoding,
 except this has constant probabilities.
 Multiplers used to encode each character
 (starting with the 1st character and going to the last),
 <br>
 <br>
 64*64*64*64*64*64*64*64*64 +63*63*63*63*63*63*63*63,<br>
 64*64*64*64*64*64*64*64 +63*63*63*63*63*63*63,<br>
 64*64*64*64*64*64*64 +63*63*63*63*63*63,<br>
 64*64*64*64*64*64 +63*63*63*63*63,<br>
 64*64*64*64*64 +63*63*63*63,<br>
 64*64*64*64 +63*63*63,<br>
 64*64*64 +63*63,<br>
 64*64 +63,<br>
 64 +1,<br>
 1,<br>
 <br>
 This evenly distributes the effect of a character across all bits.
 The synthetic all {1,2,3} length string case performs better 
 with this encoding. 
 The english dictionary does not see much of an improvement.
 <br>
 <br>
 A forth option would be to just use arithmetic encoding,
 or predictive arithmetic encoding on the string.
 I suspect this would have similar results 
 on the english dictionary as the above 
 fixed interval encoder had on the all possible strings case.
 However I didn't try it, 
 because I don't have any great way to 
 get symbol probabilities for source that does not exist yet,
 and current results are probably good enough.<br>
 <br>
 <b>Hash Cache Utilization</b>
 <br>
 Solving (c.) hash cache utilization: how about a software hash cache.
 Source tends to have a small working set of words, 
 even if the dictionary gets quite large.
 Now that hashing to different size tables is free via AND,
 I can split the hash table into two parts: a 256 entry table (or larger)
 which will effectively always be filled and in hardware cache,
 and a much larger table for software misses which still wastes 75% of the hardware cacheline. The software hash cache contains the following per entry,<br>
 <br>
 {4-byte data, 4-byte larger table address, 8-byte string}<br>
 <br>
 The larger table is inclusive.
 Eviction of the small hash uses the larger table address,
 to avoid searching (or probing) for the right entry.<br>
 <br>
 <b>Moving On</b>
 <br>
 This should have the right combination of being simple enough
 and fast enough to avoid triggering the "something is wrong" 
 re-design impulse again.<br>
 <br>
 The high-level view I have of the OS
 is effectively an ultra-high-power micro-controller
 that boots into a forth editor like a C64 boots into basic...
 <br>
 </div></body></html>
@@ -0,0 +1,56 @@
 <html><head><link rel="stylesheet" href="style.css"></head><body><div class="page">
 <h1>20150525 - OS Project : 7 - PS/2 and Misc</h1>
 <br>
 Just started back up again after a long break.
 Finished up the PS/2 driver.
 Simplified keyboard interface to one 64-bit bit array in memory,
 and a simple polling function.<br>
 <br>
 <pre>   __0 __1 __2 __3 __4 __5 __6 __7 __8 __9 __A __B __C __D __E __F
 0| 0   1   2   3   4   5   6   7   8   9   A   B   C   D   E   F
 1| G   H   I   J   K   L   M   N   O   P   Q   R   S   T   U   V
 2| W   X   Y   Z   `   -   =   [   ]   \   ;   '   ,   .   /   SPC
 3| LF  RT  UP  DN  HOM END PUP PDN INS DEL BS  TAB RET SHF CTL ALT</pre>
 <br>
 Key down sets a bit.
 Key release clears bits for {SHF, CTL, ALT} only.
 It is up to the application to clear bits otherwise.
 Ended up being a good design choice as keys like '\'
 immediately generate release commands even when held down
 on my keyboard.
 Key bitmap organized to make editor usage (like key-to-hex conversions) simple.
 Keys limited to what I expect to use, and
 supporting everything on typical <a href="http://www.xgaming.com/support/questions/17/PC+%26+MAC+%28Mode1%29+Button+Layout">PC arcade controllers</a>.<br>
 <br>
 <b>Multitasking</b>
 <br>
 Humans and modern computers share a common thread: 
 neither is any good at multitasking.
 The context of multitasking in this post is not async IO,
 but rather running multiple applications at the same time on the same CPU core.
 Suspect that the needs of multitasking change quite a bit 
 at the point where nearly everything on the machine is 
 perceptually instantaneous: 
 as it would be once the 30 years 
 of 40% yearly compounding complexity dept is removed.
 SSDs have throughput similar to last-level cache on early P4 era PCs.
 Logical end point: CPU cores owned by the applications themselves,
 no single-core multitasking, no preemption.
 App using power control to drop CPU core to lowest power state required 
 to sustain a hard real-time user interface.
 </div></body></html>
@@ -90,7 +90,9 @@ Below this is active random migration (400 prior posts still to filter through)
 <a href="20150710.html">20150710 - Inspiration Reboot</a><br>
 <a href="20150709.html">20150709 - GPU Unchained ASCII Notes</a><br>
 <a href="20150630.html">20150630 - Sugar Free Peppermint Chocolate Chip Custard Ice Cream</a><br>
 <a href="20150525.html">20150525 - OS Project : 7 - PS/2 and Misc</a><br>
 <a href="20150522.html">20150522 - The Other Project Cleaned Up</a><br>
 <a href="20150509.html">20150509 - OS Project : 6 - Hashing</a><br>
 <a href="20150430.html">20150430 - The Other Project Getting Wired</a><br>
 <a href="20150426.html">20150426 - Source-Less Programming : 5</a><br>
 <a href="20150424.html">20150424 - Source-Less Programming : 4</a><br>