hintron / computer-enhance Goto Github PK

Right now, -h/--help fails when there are any args after it that fail to parse. What I would expect is that -h/--help will short circuit the arg parsing so it doesn't matter what args I have afterwards.

• https://www.computerenhance.com/p/8086-decoder-code-review
• https://www.computerenhance.com/p/8086-simulation-code-review

Now that I have successfully implemented my decoder/simulator to the point where I satisfied ALL listing files in part 1, I am ready to do a full dive into Casey's code. I don't really intend to change my code to match his, but I do want to see how a good programmer does things. I will follow along in my own code editor, just so I can see the code better.

Satisfy listing 43.

Watch the next lesson about simulating memory and implement listings 51, 52, and 53.

This shouldn't be too hard - all I need to do is add a big memory array and access it during execution.

Right now, execution is opt-in with --exec. I want to invert that so execution is the default, and a plain decode is opt-in with --decode.

Right now, I print tons of stuff to stdout. I want to squelch all of that unless a verbose flag is specified. That should speed things up a bunch.

One of the class participants created a Snake game in 8086 here: https://gist.github.com/charlesastaylor/18c7c8005fed9d0af1a3ee2b24fcd724. I want to try to run this!

Tasks to be able to run this code:

• Get a windowing solution working (I may need to run this on Windows instead of WSL for that to work, or figure out how to get windowing code working in WSL)
• Implement jmp
• Implement int
• Implement an input "register" at 0xFFFE and hook up keyboard keypresses into that register

I also want to compile this code and run it through my decoder, just as another decoding regression.

After a few frames, the Snake game looks like this (macOS, but it's the same on Windows and Linux):

Things turn green, the top gets garbled, and the snake stops moving.

I used to have it so that the snake was continually moving left to right and then back around again. So that leads me to believe that perhaps I am messing up the softbuffer buffer somehow, and the underlying assembly is still good.

I need to step through this with the debugger to see what is going on.

Implement listings 59 - 64 from lesson From 8086 to x64.

As part of this, I need to implement a --stop-on-ret argument that will just simply quit the simulator when it sees a ret. The rest of the code should run as is on my simulator.

Here is a link to the Compiler Assembly output for listing 58 (it's at the bottom of the file).

In order to simply decode my RTOS while NOT executing it, I need to have "skip sections" where I can skip parts of the program that are just data or spacing rather than code.

In order to run my 8086 RTOS, I need to give the CPU an initial IP state so it starts at 0x100. I might add well also give it the ability to specify other registers to a starting state as well

These are two separate binaries and code bases, so I would like to have them be separate Cargo workspaces.

Watch the next lesson about simulating conditional jumps and implement listings 48, 49, and 50.

The biggest change will be keeping track of the instruction pointer. This might require re-architecting how I loop through instructions, or perhaps I will need to build some kind of lookup table for addresses and instructions.

Currently, I can't run the regressions on Windows because I don't have NASM installed on Windows. I can run the regression script just fine with Git Bash, but I can't compile the 8086 toolchain's NASM because I don't have make, and even if I used something like chocolatey to install make, I would need to install g++ and all that.

The most promising option is just to save off the compiled assembly binaries Into the regressions source files, and cut out the NASM step. Then, if I want to change any of the assembly, I just need to recompile them on a Linux machine.

What I could do is have a script that recompiles the assembly on non-Windows machines and checks to make sure they haven't changed before running regressions. If they have changed, then quit the regression so I can address it.

I would have already switched over from BTreeMap to some kind of indexed array, because I assume it will be faster, but I wanted to leave this decision for later in the course when I have the tools and methods needed to profile and investigate performance. So I don't want to change it just yet.

I want to start printing out emulator prints to a text box in the graphical window output, and perhaps ab_glyph is the first step to rendering fonts.

Of course, it may be a big pain in the neck to display print output in a graphical window instead of a terminal, so even if I can do it, I might not want to. But I could at least possibly use it to print out various overlays to the image, like key presses or other things.

Create a cache of decoded instructions, so that if I run into the same instructions over and over I can skip the entire decode step and just execute it. Since 8086 programs are so small, I should have tons of memory available to cache probably most of the program. It will be interesting to see just how much faster I can make things with that. This change should be relatively easy to make, as it doesn't need anything from the execution side, and only needs types from the decode side.

I want to be able to analyze the performance of this change, so I will hold off on making it until I am ready to do performance analysis.

I want to record time from start to finish for individual runs, as well as for the regression suite as a whole. I want to start doing simple performance tests with that.

Enable a mode for interactive debugging from the command line, like emu86. This will help for long-running, never-ending programs, like my RTOS. Eventually, running my RTOS as a regression will be unfeasible, because it will run too long.

This will make it easier to tell the execute module what to do. Currently, the decode module decodes source and destination registers directly into a string. I don't want to pass this data between the modules as strings.

Tasks:

• Quiet all prints when measuring performance. Prints will kill performance.
• Build it in production mode
• Measure decode only and simulation/decode
• Run each simulation and each decode file multiple times. Shoot for 30 seconds each for simulation and decode.

Display the # of frames rendered per second in the graphical overlay, and if no new frames were rendered in the last second, either display 0 or nothing at all.

Implement listings 56 and 57 from lesson Estimating Cycles.

Implement listings 54 and 55. This will require #11 if I want to print out the program code as part of the memory image.

While I have int and iret implemented, I do not yet model the Programmable Interrupt Controller (PIC) or track any interrupt state. That is necessary for interrupts to actually work. And interrupts are necessary to get Simptris working.

Basically, I should partially revert commit af1c41b and tweak listing 56 so that the ea clock cycles are back to what I would expect. See cmuratori/computer_enhance#59 for a detailed description.

Now that I have an RTOS regression running at IP offset 0x100, I can start decoding and simulating my RTOS binary!

I haven't yet implemented jmp apparently, so that is the first item on the list.

After reviewing the simulator reference code in #25, I see that I still need to implement timings for rep insts. I already count the # of shifts and factor that in for timing, so I should do something similar for rep.

There are a few issues with how I execute arithmetic instructions. Some that I've noticed:

• Half-byte subtraction does not handle overflow - it panics instead.
• Half-byte addition (and probably all arithmetic instructions) overwrite the destination instead of adding to it.

The class listings (up to listing 57) did not require a rigorous implementation of these instructions - they didn't care if add overwrote values instead of added to them. However, in order to implement the last class listings in part 1 (listings 59-64), I need to get these working.

I think I will work on fixing these first (without worrying about cycle timings), then resume work on #21 once I am confident that my execution code works well.

Currently, the pixels from memory and the pixels in the output window are 1:1, and this makes it really small. I want to enable an arbitrary scale factor. I'll start out with an integer scale factor, and once that works, try to get a float-based scale factor working.

Have a "minimap" of memory and registers that will graphically show reads and writes. Perhaps have a read, a write, and a read-write minimap. Have it heat-mapped so that more recent accesses are visible as red, the least-recent accesses are green and blue, and untouched accesses are black. Also have separate minimaps for code and data accesses.

Create a program that generates a JSON file with haversine pairs, as described in lesson "Generating Haversine Input JSON".

(Original haversine distance problem description)

The memory width gets set to Hi8, which makes it so that the source byte gets stored at addr + 1 instead of addr.

Currently, memory is word-addressable, and is only pseudo byte-addressable because I read out a word, change a byte, and write back a word. I should really have byte-addressable load/store functions in addition to word-addressable load/store functions.

After reviewing the simulator reference code in #25, the manual has min and max values for multiplication and division, rather than just a single timing value. So I should add in a "max" value. Do I print both? Probably. I could take the max and add it to the total clocks. Alternatively, I can take the average, rounded up, and add that to the total.

See https://www.computerenhance.com/p/8086-simulation-code-review at the 6:50 mark.

The problem I am having right now is that when I display a frame to memory, I create an event loop and winit window ad-hoc. So I can't render the next frame without leaving the loop. Somehow I need to create this window in a separate thread, and then have it live between instruction iterations so I can render to it.

I think the simplest way to do this is to create a graphical window on execution startup, and have it waiting around until we need it. Another alternative is to create it ad-hoc when we need it, and somehow save off the pointers to it and use it on the next iteration (though I'm not sure how easy that will be in Rust - it should be doable with a move, but who knows).

If I can get a general purpose graphical output working, then I can split it up so that some of it is the true program's output, some of it is a memory mini-heatmap, and some of it is register and instruction visualizations. Then I can eventually turn this emulator into a true debugger, like emu86.

Use Rust to create some kind of cross-platform window that displays Simptris. I think I can do better than ascii art - perhaps I can use the RGBA raw output method to render nice pre-made pieces to the screen.

"Input is handled via the input "register" at memory address 0xFFFE, with each bit corresponding to an input button. Starting from the low bit the buttons are: Up, Down, Left, Right, Menu. Ie the low bit is used for the up button, the 5th bit is used for the menu button, and the top 3 bits are unused."

| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
---------------------------------
| x | x | x | M | R | L | D | U |

Watch the next lesson about simulating add, sub, and cmp, and implement listings 46 and 47. The big difference is that now we need to keep track of a flags register, and we need to do arithmetic. Note: cmp is just sub but without storing the result.

Currently, the loaded program is in a read-only data structure, while the program memory is in a completely separate structure. So there is no way to modify the code at run time, and the code will not show up in memory at the end of if the program. It would be nice to combine these two spaces into a single space, as that is what Casey's simulator does in lesson "Simulating Real Programs."

This may require unsafe rust, since I'll be iterating over the code in memory while modifying it.

There are a few approaches for checking exit_after - I'm curious which one is better.

One way is to match outside the loop first to see if it's set, then if it is, check it inside the loop.

Another way (the current method) is to match inside the loop for existence and do the check at the same time.

I've been trying to do this, but I can't seem to correlate the assembly created by cargo asm with the debugger assembly. The instructions and stack offsets are slightly different, and I'm not sure why.