mdk/mixlib, branch master

Fix: missing MIX_CMD_SBT

2022-01-16T16:42:48Z

Thanks to Kevin Sun.

Year range in --version messages

2020-10-19T03:26:12Z

Use g_error_free

2020-10-18T17:47:30Z

G_INLINE_FUNC deprecated

2020-10-18T16:55:37Z

Change vm->address_list from GSList to GQueue

2019-04-09T01:59:08Z

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

Support IOC commands for disk/drum devices

2019-04-09T01:40:05Z

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.

Fix: correctly rewind tape

2019-03-20T00:06:22Z

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.

Fix: allow access to last mem cell in devices (#9773)

2019-03-19T01:13:46Z

Author: Kevin Brunelle

Fix for mixasm infinite loop on invalid F-specs (bug #32452)

2019-01-08T18:02:00Z

Thanks to Sascha Wilde.

Fix for bug #43634: keep sign of rA for ADD/SUB yielding 0

2019-01-08T05:22:16Z