swp-uebersetzerbau-ss13 / common

Shared files between teams.
1 stars 0 forks source link

Intermediate Code Generator #1

Closed fub-frank closed 11 years ago

fub-frank commented 11 years ago

Comments and Discussion for Intermediate Code Generator See Wiki page: Intermediate Code Generator

marcowallischprinz commented 11 years ago

Hi guys, I just wanted to ask, whether we can assume in the backend, that all sytactic and static semantic errors already have been detected, that the necessary type chcking has taken place and that type-conversion operators have been inserted whereever necessary or whether we have to care about any of those things? BR

fub-frank commented 11 years ago

Yes, you can consider the generatec Intermediate Code type safe and error free. Semantic and syntactic checks have to take place before generating the intermediate code.

In fact the AST given to the Intermediate Code Generator is considered error free as it has already passed syntactic and semantic checks. From a valid AST the Intermediate Coode Generator guarantees valid TAC.

If the AST given to the intermediate code generator is invalid the behaviour is unspecified. This should never happen. If it happens, there are errors in Lexer, Parser or Semantic Checker.

marcowallischprinz commented 11 years ago

Just to get it right, we've decided in favor of "bottom-up"-calls, right? So the Lexer calls the Parser etc...? I think, last week our group was in favor of the other direction. That doesn't matter, but there might be some confusion about which group has to define what interface...

marcowallischprinz commented 11 years ago

Ahh, but there is a nice picture in the wiki. Great... :)

fub-frank commented 11 years ago

I just uploaded this picture to keep track of the progress groups make. I didn't intend to show call hierarchy with this picture.

I think we decided like this last thursday: All Components return the complete result, not just (in this case) token by token. So calling the lexer would return the complete sequence of tokens. Results are handlet by the main controller that controlls all components and data flow. This controller takes the result from one component and calls the next component. Because we wanted to stick to the lecture we made an exception for lexer parser. As far as i remember this was the plan:

  1. controller instantiates the lexer
  2. controller instantiates the parser
  3. controller passes lexer instance to parser
  4. parser calls lexer.
marcowallischprinz commented 11 years ago

Okay, I think we wanted to do it in this way as well. Same story with backend and ICG?

marcowallischprinz commented 11 years ago

Ah no, we wanted to it always like in your lexer-parser-situation...

marcowallischprinz commented 11 years ago

Maybe we should discuss this again...

fub-frank commented 11 years ago

It is not part of the intermediate code generator. If you want to discuss Controller architecture, open a new issue please. Anyway controller structure is independant from the module interfaces. If the interface is defined, it does not matter who calls it.