| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The current emulator uses an unbounded linked list for tracking the
memory locations our program has traveled through. On a 64 bit system,
this requires 16 bytes of data for every instruction a MIX program
performs. For small programs that are light on computation cycles,
this does not cause a noticeable issue.
For programs that execute hundreds of millions of instructions, this
causes the memory footprint of the virtual machine to explode. I have
attached an example MIXAL program that will cause the VM to grow to
over 3 GB of memory usage when run.
To run the sample, compile coin-opt.mixal (attached), run it in mixvm,
and enter 499 at the prompt. Or use the following steps.
This patch changes all the appropriate references to GQueue references
and also caps the backtrace at 1000, which can be changed in the
mixlib/mix_vm.h header. I feel like 1000 is a reasonable limit for the
vast majority of debugging needs. Most people are looking back at the
most recent 100 instructions or so.
You can get the original behavior (unlimited tracing) back by setting
the MIX_MAXTRACE to -1, albeit with a slightly higher memory cost (24
bytes per instruction). Or you can turn it off entirely by setting it
to 0.
Using a queue doesn't change the logic of the program in any
significant way, and it allows programs to run for an extended period
of time without consuming all the memory on the machine and slowing
down to a crawl.
-Kevin Brunelle
|
|
Patch by Kevin Brunelle
The console input in gmixvm will only read 70 characters, but the
outer loop used 70 (the characters) instead of 14 (the number of
words). This caused the VM to read past the end of the buffer and
write 56 words of junk into the emulator.
|
|
Thanks to Kevin Brunelle
There is a minor fix included with regards to tape devices. The test
was failing if M == 0, when it should fail when M != 0.
NOTICE: This patch changes the behavior of the VM and changes the
function parameters for the ioc_ function. Documentation changes are
included.
Permits the following:
LDX BLKNUM
IOC 0(8)
OUT ADDR(8) Write block from ADDR into disk[BLKNUM]
IOC 0(8)
IN ADDR(8) Read block from disk[BLKNUM] into ADDR
...
BLKNUM CON 45000 Example possible block on disk
I was having an issue writing a block to a drive and then reading back
the same block. Because it is impossible to move the SEEK_CUR pointer
backwards on a disk device, there was no way for a program to read
back a block that it wrote to a disk without restarting or fiddling
with ~/.mdk/disk?.dev files and symbolic links.
I have added a function parameter to the ioc_ function and used it to
pass the value of rX to ioc_. This permits us to use IOC commands to
move the read/write head on a disk/drum device. I believe that this
conforms to the potential meaning of Knuth's description of IOC for
disk/drum devices.
I have put in tests to verify that rX is positive and M = 0.
I have updated the documentation to reflect this new behavior.
This makes disks much more usable.
Note: I won't be offended if this patch is rejected because it changed
the behavior of the VM. I think it fits the spirit and enhances the
functionality in a way that some might find useful. I wanted it for
something I was working on, and I felt others might want the same. The
thing with the paper-tape should be fixed, though.
|
|
|
|
According to the specification, if M < 0, the tape is skipped backwards M
blocks, or to the beginning of the tape, whichever comes first. In the
implementation, we don't check to verify that we aren't seeking past the
beginning of the file. This causes fseek(3) to fail, and it leaves us at the
position we were at.
Diagnosis and fix by Kevin Brunelle.
|
|
|
|
Author: Kevin Brunelle
|
|
Thanks to Thomas Matecki. Fixes #bug 55877 and makes mixvm, Philip
King's child, work again!
|
|
|
|
|
|
Thanks to Sascha Wilde.
|
|
|
|
We were taking only the first 3 bits of the index byte in a the word
representing immediate constants, so that, for instance, =262143=,
representing 00 00 63 63 63, was stored as 00 00 07 63 63.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
