Scribd Logo
Upload

Welcome to Scribd!

  • 7 views

    Compiler S

    Uploaded by

    Jhonatan Bautista

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Compiler S

    Uploaded by

    Jhonatan Bautista
    7 views2 pages

    Original Title

    Compiler s

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    7 views2 pages

    Compiler S

    Uploaded by

    Jhonatan Bautista

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    You are on page 1of 2

    we're going to give a very brief introduction, an

    overview, of what we're going to be talking about in semantic analysis. Let's

    take a moment to review where we are in our discussion with compilers. So we

    talked about lexical analysis, and from the point of view of enforcing the

    language definition the main job that lexical analyses does is detect input

    [inaudible] preemptive symbols that aren't part of our language. The next step is

    parsing. We finished talking about that too. And, again, from the point of view of

    trying to determine whether a program is well-formed or not, or whether it's a

    valid program, the job of parsing is to detect all the sentences in the language

    that are ill-formed, or that don't have a parse string. And finally What we're going

    to talk about now, what's going to occupy us for a while is semantic analysis. And

    this is the last of what are called the front end phases. So if you think of

    lexical analysis, parsing, and semantic analysis as filters that progressively

    reject more and more input strings until finally you're left after all three phases

    have run with only valid programs to compile, well semantic analysis is the

    last line of defense. It's the last one in that pipeline and its job is to catch all

    potential remaining errors in a program. Now you might ask yourself, why do we even

    need a separate semantic analysis phase? And the answer to that's very simple,

    There are, there are some features of programming languages, some kinds of

    mistakes you can make that parsings simply can't catch. Parsing we'll use in context

    free grammars is not expressive enough to describe everything that we're interested

    in, in a language definition. So, some of these language constructs are not context

    free. And the situation here is very, very similar to what it was when we switched

    from lexical analysis to parsing. Just like not everything could be done with a

    finite [inaudible]. And we wanted to have something more. Our context free grammar

    to describe additional features of our programming languages [inaudible] Grammars

    by themselves are also not enough, and there some additional features beyond

    those that can't be easily expressed using context free constructs. So what does
    semantic analysis actually do? In a case of cool C, it does checks of many

    different kinds, and that's pretty typical. So here's a list of six classes

    of checks that are done by Cool C, and let's just run through them quickly. First

    we want to check that all identifiers are declared, and we also have to check that

    any scope restrictions on those identifiers are observed. Cool C compiler

    has to do type checking, and this is actually a major function of the semantic

    analyzer in Cool. There are a number of restrictions that come from the object

    oriented nature of Cool. We have to check that the inheritance relationships between

    classes make sense. We don't want classes to be redefined; we only want one class

    definition per class. Similarly methods should only be defined once within a

    class. Cool has a number of reserved identifiers and we have to be careful that

    those aren't misused. And this is pretty typical; lots of languages have some

    reserved identifiers with special rules that have to be followed for those

    identifiers. And, actually this list is not even complete. There are a number of

    other restrictions. And we'll be talking about all of those in future videos. The

    main message here is that its medic analyzer needs to do quite a few different

    kinds of checks. These checks will vary with the language. The kinds of checks

    that cool C does are pretty typical of statically typed checked object oriented

    languages. But other families of languages will have different kinds of checks.

    You might also like