Made a lot of progress today.
I just wrote a "hello world" program and got it working so the UART
output shows up on the simulator.
Took a bit more work as there were a couple of subtle bugs lurking in
paths I hadn't fully exercised
previously (it's the nature of things). It was more complicated by the
fact that this is the first time that
the "timekeeping" code has been executed (when a character is sent over
the simulated UART, a timer
is set in the simulator that determines when to clear the transmit busy
flag). That code had a few issues
but it's all working well now.
The way that the timekeeping code works is that time advances only as
each instruction is executed.
Therefor, you don't have to worry about time dependent code behaving
poorly when instruction execution
has halted (such as hitting a breakpoint).
I also updated the code that generates the assembler listing so that the
ALU instructions are fully
decoded. Makes it much easier to figure out what's going on when I'm
debugging the J1 code. The simple
forth programs I was using prior to the "hello world" program didn't
present too much of a problem but
as the programs are becoming more complex, having a "reasonable" listing
makes a world of difference.
I also added the capability to "break" into a running program by
entering a ^D on the keyboard. Not
sure if I'll keep it as ^D or not but for now it allows me to interrupt
the execution of the J1 program.
It's useful when the code is looping and not hitting any of the set
breakpoints. ;-)
I have a few more things to try out with the UART (like character input)
before I move on to testing out
the simulated FRAM.
TTFN - Guy
On 7/20/15 2:04 PM, Guy Sotomayor wrote:
As I mentioned previously, I took some time off from
working on the
MEM11 for the past several months.
I had some time over the past few days, so I spent it working on the
simulator.
Right now all of the J1 instructions seem to simulate properly.
Everything related to the basic simulator
also seems to be functional. I still have work to do to write code
for the simulated I/O (it's all stubbed
out at the moment). The way that I'm implementing the I/O, is that
it's pretty modular. All of the
fundamental code structures are there, I just have to write the
"handlers" for the particular I/O devices.
I wrote the majority of the J1 simulator to be H/W agnostic (as far as
the I/O is concerned), the I/O
at this point will match what I expect to be in the actual MEM11 H/W.
Here's what the simulator currently supports:
- All command functionality is present and functional. These are
the way that one interacts with
the simulator. The commands include things like:
- loading files into J1 memory or FRAM
- dumping memory locations from J1 memory or FRAM
- modifying memory locations in J1 memory or FRAM
- setting, listing and clearing breakpoints
- starting execution
- single stepping execution
- dumping the data & return stacks
- starting and stopping instruction tracing
- All of the J1 instructions now seem to execute correctly (lots of
typo's and other subtle bugs)
- Exceptions work now. This allows the J1 program to do something
"silly" and the simulator
won't crash (had enough of that already while I was debugging
the simulator!).
It'll report what the J1 program did that was "silly" (ie
unaligned memory accesses, etc).
- It also contains a reasonable "help" system.
I've written an instruction test program that tests out all of the J1
instructions and it is "self checking".
That is, it will throw an exception (unaligned address) if the result
of the instruction test isn't what
was expected. To determine what failed, I look at the address where
the exception occurred and
reference the test program listing to determine which test failed. I
verified that it is indeed operating
correctly by hand checking via the instruction trace file that it was
doing the "right things".
I had originally started debugging by single stepping through the
program but after the test program
grew to over a few dozen instructions, it became too tedious for me to
ensure that I was accurately
verifying the instruction execution. This is where the instruction
trace file became invaluable.
The next thing to do is to work on the simulated I/O. Once I'm
confident that all of that is working
then I can go about debugging all of the code I've already written for
the MEM11 itself. The simulator
should give me a pretty good environment for debugging, especially
when compared to the actual HW.
Oh, and of course everything (simulator, MEM11 firmware and tools for
the build environment) are all
written in forth. ;-)
TTFN - Guy