erickahmed / iceberg

Iceberg is a virtual FPGA computer built from scratch using Systemverilog
GNU General Public License v3.0
6 stars 2 forks source link

Creation of an assembler #3

Open erickahmed opened 2 years ago

erickahmed commented 2 years ago

As for the compiler, we also need an assembler, and it also needs to be a basic assembler that can translate C code. I think it will be fun to create on from scratch

AdamLaine commented 2 years ago

@erickahmed An assembler is a type of computer program that interprets software programs written in assembly language into machine language, so can I ask you what do you mean by "translate C code"? Also looking the thing you mentioned "nand2tetris" (hopefully I used the correct link https://www.nand2tetris.org/course ) they used their own custom assembly if I understood correctly, which then is translated to bit code (they have .hack files), so do you want to do something like them, maybe even with the similar assembly syntax?

erickahmed commented 2 years ago

@SamReiCooper In nand2tetris they used their own assembly-like language, that you could either write manually or generate that from their Java-like language. I was thinking something very similar but using assembly, or some custom variant that resembles x86 assembly syntax (but if the latter if not feasible, then I'm also happy with a simpler custom assembly)

For "translating C code" I actually meant just generating the bytecode from the assembly, that in turn is generated from C. Sorry if that was confusing, actually the part I was referring for the assembler was asm-->bytecode, and C-->asm part is related with issue #2. I mixed up things, sorry for that

By the way, we could use something different than C if we wanted, I just thought that for generating assembly C was the best choice. If you want, you can propose something different

Also I guess that it will be necessary to modify the Verilog code a bit and make sure everything is correct and working, before we will have to do any testing

AdamLaine commented 2 years ago

@erickahmed If I may give a piece of advice, I will definitely propose to modify and finish the Verilog part, so as to have a perfectly working minicomputer with perfectly defined bit instructions (from what I quickly saw there was still some unfinished stuff, correct me if I'm wrong). Then it will be easier to think of how to create at least a basic assembler and after that it will be also possible to think of a compiler. Creating an x86-similar assembly language shouldn't be that much of a problem especially provided how strict in general assembly syntax is. For this reason there will be also the necessity for a basic parser, so C should be more that enough. The option of what I see is to create a hash table (in C though we'll have to do it from zero) mapping every command, possible registers and etc to the strings of bit codes, though I am still reading and thinking of how to use them later. What I propose now is for you to create GitHub issues on all known to you problems and unfinished Verilog stuff of the project so as I and possibly other interested developers will be able to work on the more quickly.

erickahmed commented 2 years ago

@SamReiCooper I totally agree! Later in the day I will list all the issues I find in my verilog code and those I already know about. Also yes, there was some unfinished stuff in the IO, and I still need to verify that I did not messed up anything in the ram. Then I will make one giant verilog script that will import every other module (cpu, ram, ecc.) and that will be capable to take bytecode in input

You can freely also open your issue if you want, for instance to decide the algorithm that the parser should have, or anything else. So hopefully we will be more organized and it will be easier for other devs to collaborate

AdamLaine commented 2 years ago

@erickahmed

Then I will make one giant verilog script that will import every other module (cpu, ram, ecc.) and that will be capable to take bytecode in input

I will need to revise my CPU architecture knowledge, but I think you are referring to the controller unit (CU) (which btw can have two architectures: the memory mapped one and the finite state machine one), which will need also to have instruction register (IR) and instruction pointer (IP). So basically you need this one first and later it is possible to connect them all (into the cpu.v file, for example, and later to the computer.v). I guess what I'll start doing is revising and testing via Verilog simulator (I'll try both iverilog and Verilator) the components watching for possible bugs and problems (and also finally learning Verilog as I know it only theoretically). At the same time if you don't mind I'll start with the compiler and assembler algorithms in C, I'm still pro hash table (the reasoning being that: the program is already at least O(N) complexity where N is the number of rows in the assembly file, I'll try to create O(1) search (possibly using an excessive memory during the compilation), so as not to make the program too slow), so I'll start programming it and then modularly creating PRs asking you to review them and tell me your thoughts. Are you OK with this plan?

erickahmed commented 2 years ago

@SamReiCooper Yes, I agree we do it like you said, I think it makes very sense. I especially like the idea for the search method of O(1) complexity. And sorry, I still did not created those issues for the Verilog stuff, I was busy with work. If it's there anything I can do on the C part, just tell me, since I wanted to improve in C and this is a good opportunity

And as for you wanting to learn Verilog in particular, feel free to work on any of the files I've written and improve them. Of course when I will make the issues (asap I promise) this will be especially true