Do we need to implement the assembler same as in the book.. I mean GUI implementation?
Can I use C language to implement it without any GUI effect?
A command line implementation is fine. An object oriented language like C++ or Java will be easier, especially if you plan on doing the follow-on software projects. I'd avoid C++ unless you are familiar with the STL. More modern languages like Java, Python and Ruby have much better support for parsing and symbol tables.
I wrote all my tools in Python since I wanted to get a better grasp on that language. I'm thinking about rewriting the whole set in Ruby which I've heard good things about but have not yet used.
i'de love to , but i find it hard to learn new language and to implement a complicated (for me) program.
im having trouble with making sense where to start the implementation
given an assembly input file, what should i do?
load the whole file to the memory then start scanning it for commands (skeeping remarks anf empty lines)
read each time only one line from the input stream\file and deal with it seperatly (if so, how should i implement the jump commands? i dont know where to set the jump to lable befor reading the all file)
i would much apriciate if you give me a guidance here
The biggest problem with using C is going to be that it does not have the any sort of mapping function in the standard library. You will need this to implement the Symbol Table for your assembler.
In Python, for instance, one can simply write
symbol_table[label] = current_addr
where label is a string and current_addr is an integer, and later
addr = symbol_table[label]
to get the address out of the symbol table. In C this requires a lot of code; you will want to search the net for "hash table" to find appropriate code.
As to how to know the address for labels, this is why you need to read the assembly source file twice. Pass 1 figures out the addresses for all symbols and stores them in the Symbol Table; it does not generate any output. Pass 2 generates the output using the symbol values saved during Pass 1.
For a reasonably straightforward C hash table, you might want to look at "uthash".
The windows distribution .zip file only has the required source files. The unix/mac distro (a .tar.bz2 file) also includes all the docs and examples. If you want all these other files and can't open the unix distro, I've converted it to a zip file you can get at http://marksmath.com/tecs/files/uthash-1.9.7-source.zip
Yes, you can do as you are talking about. You will need a fairly long pointer array; Pong.asm has nearly 900 symbols; my game has closer to 1200. Also, the symbol names generated by the VM translator can be rather long so you'll want to dynamically allocate them too.
Looking up a symbol name in this array will be slow, but it will work.
I'm just starting this chapter, my line of thinking is to make a 2d array as a look up table for the assembly to binary conversion and then write script that loops through the assembly code converting it to the respective binary.
That should work fine. What you are describing is called a "map" or a "dictionary" in some languages. You might see if VB.net supports something like that. If they do, then you might consider using it as it will abstract away some of the lower-level details -- unless you want to deal with those details, which is a perfectly reasonable and doable objective in this case.
What is best practice when creating the symbol table?
Declaring it as a local array in a function means it will be overwritten each time the function is called. On the otherhand I am told using a global array isn't a good idea.
I'm using VB.net and have managed to get the symbol-less version of the code working just fine, but the symbol bit is proving tricky.
Depending on the capabilities of the language, using a static array or an array that is an instance variable of an object are both reasonable. Another is to declare the array in the main function and then pass access to it to the functions that need it. Generally speaking, global variables should be avoided, particularly if they are being used just for convenience. But they do have their place and sometimes that are perfectly reasonable and valid ways to do something. Personally I would agree that this is not one of those situations.