The speed of CPUs has been increasing than the speed of memory, meaning that the number of CPU cycles that must be delayed because of a cache miss is increasing.
An LR(1) grammar can be recognized by a bottom up parser that can see the whole right hand side of a production plus the next token, while an LL(1) grammar must be recognied by a top down parser that can only see the next token before deciding which production to use to expand the current non-terminal. Hence LR(1) grammars are much more expressive than LL(1) grammars.
If the predict sets do not intersect, then a predictive compiler will always be able to guess which production to use to expand the current non-terminal by looking at the next token and choosing the production whose predict set contains that token.
Pointers set up aliases that make it difficult for a compiler to determine which variables may be affected by a read or a write, thus making it more difficult to determine dependencies between variables.
Exp -> Atom | Opn Atom -> number | id Opn -> ( + Exp_List ) | ( * Exp_List ) Exp_List -> Exp_List Exp | Exp
Exp_List -> Exp -> Opn -> ( + Exp_List ) -> ( + Exp_List Exp ) -> ( + Exp_List Exp Exp ) -> ( + Exp Exp Exp ) -> ( + Atom(a) Exp Exp ) -> ( + Atom(a) Atom(23) Exp ) -> ( + Atom(a) Atom(23) Opn ) -> ( + Atom(a) Atom(23) ( * Exp_List ) ) -> ( + Atom(a) Atom(23) ( * Exp_List Exp ) ) -> ( + Atom(a) Atom(23) ( * Exp Exp ) ) -> ( + Atom(a) Atom(23) ( * Atom(16) Exp ) ) -> ( + Atom(a) Atom(23) ( * Atom(16) Atom(44) ) )
Exp_List | Exp | Opn | ( + Exp_List ) | |----------------------| Exp_List Exp / \ | Exp_List Exp Opn | | | Exp Atom(23) ( * Exp_List ) | / \ Atom(a) Exp_List Exp | | Exp Atom(44) | Atom(16)
class Menu { protected: string selectedItem; listAnswer the following questions:*menuItems; public: getSelectedItem() { return selectedItem } Menu(list *items) { menuItems = items; } virtual void draw() = 0; }; class PulldownMenu : public Menu { public: void draw() { ... code that references selectedItem and menuItems ... } };
yes: If a method in PulldownMenu references a variable that is not declared in PulldownMenu, then the compiler will look to see if that variable is declared within Menu. Hence PulldownMenu is logically nexted within Menu.
0: predefined names 1: global names 2: Menu 3: getSelectedItem 4: Menu 5: PulldownMenu 6: drawThe declaration of draw as virtual in Menu does not create a new scope because it is simply a declaration, and not a definition of a function.
------------------------------------- -------------------------------- | Name Category Scope Type | --> | Name Category Scope Type | | Menu type 1 ---- | | Menu constructor 2 ---- | ------------------------------------- --------------------------------
------------------------------------------------- | Name Category Scope Type | | selectedItem inst. var. 2 string | -------------------------------------------------
------------------------------------- | Name Category Scope Type | | draw function 5 void | -------------------------------------
(1) r1 = A (2) r2 = B (3) r2 = r1 + r2 (4) C = r2 (5) r1 = D (6) r2 = r1 + 5 (7) E = r2Assume that loads and stores to memory have a one-cycle delay (i.e., require 2 CPU cycles) and that arithmetic can be done in a single cycle. Answer the following questions:
(1) (2) delay (3) (4) (5) delay (6) (7) delay
1->3, 2->3, 3->4, 5->6, 6->7
2->3, 3->6, 1->5
(1) r1 = A (2) r2 = B (3) r2 = r1 + r2 (4) C = r2 (5) r3 = D (6) r4 = r3 + 5 (7) E = r4
(1) (2) (5) (3) (4) (6) (7) delayRationale: