: The RSS feed
for this course.
Nov-20: Many people are having difficulty with the recursive aspect of Lab 6. It is due tonight at 11:59 pm, so I recommend that you do your best and that you submit your work on time. Don't panic: Not all problems that I pose to you are ones that I expect everyone to complete. After break, I am happy to meet with anyone who failed to work out the recursive solution in order to get it right.
Nov-17: The lab is not available tomorrow, so we will be meeting at our normal lecture time and in our normal lecture classroom. You should come prepared to address the following question: How does the Magical Instruction Fetcher work? I expect every one of you to have ideas on how to get started with the answer to that question.
Nov-14: I have altered the assembler and the simulator to use the new, consistent interpretation of labels and dereferencing of labels. That is, now, +foo evaluates to the main memory address labeled foo, while *+foo evaluates to the word stored at the main memory address labeled foo. This change may require some alterations in your assembly code, and it certainly requires re-assembling any existing code before running it on the simulator.
Nov-11: Ah, another bug. Specifically, attempts to JUMP to locations expressed as indirect operands (e.g., *%G0) fail. The wrong location is loaded into the program counter, and once that happens, the next instruction is likely to trigger the dreaded BUS_ERROR as the instruction is fetched from an invalid location.
This problem is going to require more than a simple bug fix. First, it will require changes to the assembler and to the simulator. Second, it will actually require you to make small changes to your code. I will fix the assembler and simulator soon, and I will post a description of the changes you will need to make to your code (and why they need to be made). In the meantime, do what you can to make progress on Lab 6. I recognize that this bug will limit your progress, and so I will extend the due date by a day or two.
Nov-11: I have fixed another bug in the k-system simulator. Specifically, many people noticed that the CALL instruction would fail with a BUS_ERROR. The cause was a mishandling, on my part, of the memory location into which the return address is stored by the CALL instruction. I have fixed it, and that error should no longer occur. Let me know if you encounter other errors that seem to occur in spite of seemingly well formed assembly/machine code on your part.
Nov-10: I have fixed two bugs for our k-system. First, directly expressed main memory addresses (e.g., @0x1000) are now correctly recognized by the assembler. Second, and more importantly, the code that I provided in count.asm revealed a substantial bug that prevented storing a result into a main memory address via indirection through a register (e.g., *%SP); that bug is also fixed, and the beginning of count.asm should now work correctly.
: The RSS feed
for this course.