Test Programs - testing symbol implementation

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Test Programs - testing symbol implementation

AlexSo
The test programs supplied clearly test for symbol labels and jumping implementation, but I don't think they test for RAM address (static variables) symbol implementation. Am I right?
Reply | Threaded
Open this post in threaded view
|

Re: Test Programs - testing symbol implementation

cadet1620
Administrator
projects/06/pong/Pong.asm has RAM variables. If your generated .hack matches the one generated by Assembler then yours is working correctly.


FWIW, my assembler generates a listing file including symbol table and cross references.  
Data Symbols

24576 D  KBD
   18 D  math.0
             6553 6559 6650 6677 6716 7065 7157 7933 8189
   17 D  math.1
             6530 7427 7537 7572 7642 7660 7690 7756 7875 7981
   19 D  memory.0
             8460 8468 8513 8565 8597
   23 D  output.0
             9895 19487 19525 19548 19748 19766 19788 20057 20080 20147 20168 20186
             20219
   22 D  output.1
             9886 19056 19539 19768 19786 20040 20071 20094 20126 20188 20206 20221
             20253 20255 20275
   21 D  output.2
             9875 18925 19093 19579 19732 19830 19842 20092 20134 20284 20298
   24 D  output.3
             9918 19981 20011
   20 D  output.4
             9863 19113 19168 19217
   25 D  output.5
             9981 17878 18533 18945
   26 D  output.6
             18486 18594 18983
   16 D  ponggame.0
             4523 4531
16384 D  SCREEN
   29 D  screen.0
             20377 20383 20474 20501 20540 21158 22704 22768 23691 23754
   27 D  screen.1
             20342 20634 20721 20739 20805 20823
   28 D  screen.2
             20354 20701 20899

Code Symbols

 5877 C  array.dispose
             25297 27015
 5808 C  array.new
             6519 6542 9970 17857 18475 18572 20366 25206 26367
...

Code size = 27483 (0x6B5B)
Data size =    30 (0x001E)
--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Test Programs - testing symbol implementation

AlexSo
That's strange as I didn't implement RAM address (static variables) symbols (I overlooked this). Yet my hack code passed the test when it was compared in the Assembler.
Reply | Threaded
Open this post in threaded view
|

Re: Test Programs - testing symbol implementation

cadet1620
Administrator
That is indeed very strange.

What code value was being written during pass 2 when A-command symbols were not found in the symbol table?

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Test Programs - testing symbol implementation

Jack Draak
In reply to this post by cadet1620
Hahahaha (laughing at myself, once again).... :)

The first time I saw your table of data, Mark, I was fairly stupefied by what I was looking at.  A damning indication that I had plenty of work ahead of me, despite my preliminary successes. (I had managed to compile a working version of Pong.asm/.hack, but I was using different memory registers... that's when I came here to poke around for ideas...)

At that time I had been using a C# Dictrionary<string, int> for my symbol-table. I saw how you've broken yours into C and D types...  I didn't see any immediate benefit to that data-point, but it did nudge me into getting off the dictionary and simply making my own class/container for symbols.  I still used the objects inside a C# List<SymbolEntry> to use List features, however.

Wow, that was way more time spent refactoring than most sane people would have applied, methinks, but... I finally got Pong.asm to compile and match the supplied Assembler!

Obviously(?) I could have just stuck with the dictionary. I think I'd have about half-as-much source-code right now, too, had I done so. Nevertheless, the exercise was entertaining and rewarding. Once my headache goes away, I'll have to go back and finish tidying/refactoring, but for now, I might have an award-winner for Most Bloated Hack Assembler:

800+ lines of C#

Thanks for the support.  Now on to chapter 7!
Reply | Threaded
Open this post in threaded view
|

Re: Test Programs - testing symbol implementation

cadet1620
Administrator
Code/Data symbol type is strictly for symbol information in the list files that my assembler generates.

Here's an example. Constants and addresses are in decimal because that's what the n2t tools use, Instruction codes are in hex because I can read the bit patterns quickly.
             // This file is part of the materials accompanying the book
             // "The Elements of Computing Systems" by Nisan and Schocken,
             // MIT Press. Book site: www.idc.ac.il/tecs
             // File name: projects/06/rect/Rect.asm

             // Draws a rectangle at the top left corner of the screen.
             // The rectangle is 16 pixels wide and R0 pixels high.
    0     0     @0
    1  FC10     D=M
    2    23     @INFINITE_LOOP
    3  E306     D;JLE
    4    16     @counter
    5  E308     M=D
    6 16384     @SCREEN
    7  EC10     D=A
    8    17     @address
    9  E308     M=D
   10        (LOOP)
   10    17     @address
   11  FC20     A=M
   12  EE88     M=-1
   13    17     @address
   14  FC10     D=M
   15    32     @32
   16  E090     D=D+A
   17    17     @address
   18  E308     M=D
   19    16     @counter
   20  FC98     MD=M-1
   21    10     @LOOP
   22  E301     D;JGT
   23        (INFINITE_LOOP)
   23    23     @INFINITE_LOOP
   24  EA87     0;JMP


Data Symbols

   17 D  address
                8   10   13   17
   16 D  counter
                4   19
24576 D  KBD
16384 D  SCREEN
                6

Code Symbols

   23 C  INFINITE_LOOP
                2   23
   10 C  LOOP
               21

Code size =    25 (0x0019)
Data size =    18 (0x0012)

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Test Programs - testing symbol implementation

Jack Draak
Thanks, Mark, for the further explanation. As I say I didn't directly see any reason to include a data-type field when I went and refactored my symbol system. Yet, the fact that you'd generated it for debug had me thinking that if I did make a field for it, then as I wrote my code it might help me see/understand something that would get me "on track".

I think the truth is, as with my CPU and other challenges in this course, that my success came when I took the time to break the problem down into bite sized chunks of pseudo-code, then bring my C# (or HDL) up to the the task. My Main() is now rather concise, consisting of little more than this:

// Pre-parse input-stream of instructions into a handy-dandy List... let's call it: instructionList.
// (Get rid of whitespace, including blank lines and comments, that's for humans, not machines.)
PreParse(args, argument, instructionList);

// On first-pass, build requisite symbol table.
// [look for label declarations, track offset]
BuildSymbolTable(instructionList, debugLog, symbolTable);

/ Second-pass, link symbol table with variables.
nextOpenRegister = LinkVariables(instructionList, debugLog, nextOpenRegister, symbolTable);

// "Third-pass", Parse variables into absolute addresses.
ParseVariables(instructionList, symbolTable);

// Parse and encode instructionList for machines* which are Hack-compliant.
List<string> encodedInstructions = DoEncode(instructionList, debugLog, ref nextOpenRegister, symbolTable);

// Output encoded data for machines*.
string programName = OutputProgram(args, argument, encodedInstructions);

// Output debug stream for humans.
OutputDebug(debugLog, programName);

...Suddenly it looks so easy.... why did it take me a week??! :)