grooben / not-c Goto Github PK

Lexemes/tokens into parse tree into Abstract parse tree.
Peter needs to do this

Complete the implementation of the intermediate code optimiser, which optimises input code before it is compiled into Intermediate code and thus into ASM.

Blank lines are being added to token stream and singular blank EOL tokens.
Parse tree gen cannot filter out as EOL tokens are important markers.
suggested: do not gen EOL for blank lines.

Needs to be edited to output code, intermediate code generation

Known issue with identifying Keywords within lexical analysis, know of a solution, but working to make it more efficient.

When performing arithmetic operations, the compiler invokes an internal function that saves data from the appropriate arithmetic CPU register into memory (_!c_memory_savereg(registerName)) essentially allowing to store results of those operations and assign them to variables. The intermediate code generator passes the name of the register for that specific arithmetic operation as a parameter to this function, which the assembly generator picks up as invalid because register names such as 'eax', 'ebx', 'edx' are not declared in static data, therefore resulting in false error messages about invalid symbol names. This can, however, be ignored and the program will still compile successfully.

@craig-clephane is having some issues getting something to return through 2 functions in the LexicalAnalysis class. Just need to bodge this...

End of line token needs to be at the end of the source file for some reason

After merging alpha into backend_asmgen (3584dab), function calls don't work with multiple parameters being passed. Will test further and try to fix. See intercodegen.py

Error handling on the lex, so other members of the team can learn and integrate with it.

Does not work, needs additional research

(Trying to add the a way to have comments within the source file)

Given a snippet of code:

Int a = 2;
Int b = 2;
Int c = a + b;

Line 3 will cause a crash (ValueError) during semantics evaluation. We could skip this but it would be useful to have semantics running so that we have type checking working.

My suggestion to this is check for math operators (+, /, -, %, *) in the assigned value, break down the string into a list of all identifiers or values present on the right side of the assignment, and then make sure they're all the same type (currently you could just check if they're all Integers and fail as soon as you find a non-Int).

Attached screenshots of Python error message and code line causing the issue.