Modelo do RTL System

O modelo de RIC utilizado pelo RTL System, que ser´a aqui designado por RTLS, ´e uma das referˆencias incontorn´aveis para este doutoramento. At´e porque serviu de base ao modelo proposto. Tamb´em aplica os princ´ıpios definidos na vers˜ao original do RTL, no entanto difere substancialmente na forma como implementa o modelo.

A principal diferen¸ca adv´em do facto de estar implementado atrav´es de uma linguagem orientada por objectos, mais concretamente Smalltalk. Por este facto, permite dotar a RIC de funcionalidades que seriam dif´ıceis de implementar sem o recurso a uma linguagem deste tipo.

O modelo ´e como tal definido atrav´es de um conjunto de classes, cuja instancia¸c˜ao permite construir a RIC. Essas classes correspondem a entidades gen´ericas que podem ser encontradas numa qualquer linguagem do tipo imperativo. H´a essencialmente dois tipos de classes, a saber:

FlowNode: Fam´ılia de classes que representam as estruturas que controlam o fluxo de exe- cu¸c˜ao do programa. Cada objecto desta classe corresponde a um elemento doGrafo de Fluxo de Controlo (GFC);

RTLExpression : Fam´ılia de classes que representam as express˜oes do programa (`a excep- ¸

c˜ao das express˜oes que definem as estruturas de fluxo de controlo).

Estas duas fam´ılias de classes permitem trˆes n´ıveis de abstrac¸c˜ao. O n´ıvel mais alto ´e obtido atrav´es da classe RTLProgram, que ´e utilizada para representar o programa submetido ao compilador. Esta classe deriva de FlowNode e mais especificamente de IntervalNode, que ´

e uma classe capaz de conter outros objectos do tipo FlowNode. No caso do RTLProgram acresce ainda alguns objectos, como o MachineDescription que caracteriza a arquitectura de computa¸c˜ao.

O segundo n´ıvel de abstrac¸c˜ao ´e disponibilizado tamb´em atrav´es de RTLProgram, mas restrito ao GFC. Com este n´ıvel de abstrac¸c˜ao ´e poss´ıvel aplicar e desenvolver rotinas de an´alise e de optimiza¸c˜ao de fluxo de controlo, sem ter que lidar com outros detalhes da RIC. O n´ıvel mais baixo de abstrac¸c˜ao, ´e disponibilizado atrav´es dos objectos derivados de RTLExpression. Conv´em no entanto explicar que o conceito de n´ıveis de abstrac¸c˜ao surge no RTLS de forma impl´ıcita. A bibliografia nada refere a este tipo de funcionalidade. O que ´

e particularmente not´orio neste n´ıvel mais baixo de abstrac¸c˜ao em que, ao contr´ario do que deveria acontecer, o utilizador apenas tem uma vis˜ao localizada da RIC. Isto porque o acesso `

as RTLExpressions faz-se atrav´es dos FlowNodes, pelo que a vis˜ao que o utilizador tem da RIC est´a restrita ao contexto do FlowNode que est´a a utilizar para aceder `as RTLExpressions. Conforme j´a se disse, as estruturas de controlo do programa s˜ao representadas exclu- sivamente atrav´es de objectos de classes derivadas de FlowNode. Classes essas que corres- pondem aos elementos base de um GFC e atrav´es das quais se constroem estruturas mais

4.2. Modelos de RIC: Estado da arte 49

elaboradas, nomeadamente estruturas condicionais do tipo if ... then ... e estruturas c´ıcli- cas, do tipo while ... do .... Essas classes s˜ao: RTLReturnNode, nodo do GFC que termina com uma opera¸c˜ao de retorno; RTLJumpNode, nodo que termina com uma opera¸c˜ao de salto incondicional; RTLConditionalNode, nodo que termina com uma opera¸c˜ao de salto condicional; e (estranhamente) RTLCallNode, nodo que termina com uma invoca¸c˜ao de uma fun¸c˜ao/procedimento, seguido de uma opera¸c˜ao de salto.

A fam´ılia de classes que deriva de FlowNode encontra-se hierarquicamente representada na Figura 4.1(a). ´E de salientar que FlowNode, enquanto classe base que representa um qualquer nodo do GFC, mant´em as referˆencias dos nodos antecessores; e que determinadas classes que derivam de FlowNode, como ´e o caso do RTLJumpNode e do RTLConditionalNode, mantˆem tamb´em as referˆencias dos nodos sucessores.

FlowNode RTLFlowNode RTLJumpNode RTLCallNode RTLConditionalNode RTLReturnNode RTLIntervalNode RTLProgram

(a) Hierarquia das classes derivadas de FlowNode. RTLExpression Storage Register SpecialRegister BitRegister Memory MemoryAccess AbstractUpdate RegisterUpdate MemoryUpdate UnaryExpression BinaryExpression Constant

(b) Hierarquia das classes derivadas de RTLExpression.

Figura 4.1: Classes da fam´ılia FlowNode e RTLExpression. `

A excep¸c˜ao da parte que diz respeito `as estruturas de controlo, o resto da RIC ´e for- mada por ´arvores de express˜oes. Essas ´arvores s˜ao constru´ıdas a partir das classes derivadas de RTLExpression, das quais se destacam as seguintes: Storage, que serve para representar registos e vari´aveis; Constant, que serve para representar constantes; UnaryExpression, que serve para representar opera¸c˜oes un´arias; e BinaryExpression, que serve para representar opera¸c˜oes bin´arias. As classes derivadas de RTLExpression encontra-se representada hierar- quicamente na Figura4.1(b).

O RTLS introduz tamb´em os RegisterTransfers, uma fam´ılia de classes que visa prin- cipalmente caracterizar as dependˆencias entre dados, mas que permite tamb´em ter uma perspectiva linear da RIC e assinalar as opera¸c˜oes que controlam o fluxo de execu¸c˜ao do programa. O RegisterTransfer ´e a classe principal, que entre outras vari´aveis, possui dois conjuntos: flowDependents, que cont´em os RegisterTransfers que fazem uso dos valores apu- rados pelo actual; e flowSupporters, que cont´em os RegisterTransfers que apuram os valores utilizados no actual RegisterTransfer. Na pr´atica, a utiliza¸c˜ao dos RegisterTransfers permite manter, como parte da RIC, oGrafo de Dependˆencias de Dados(GDD).

Os FlowNodes, RegisterTransfers e RTLExpressions est˜ao relacionados da seguinte forma: cada RTLExpression est´a associado a um RegisterTransfer ; cada RegisterTransfer pertence a uma lista que faz parte de um FlowNode. Esta rela¸c˜ao est´a ilustrada na Figura4.2, em que RTLJumpNode ´e o FlowNode, Assignment ´e o RegisterTransfer, e Mem, Add, Cnst

e Neg s˜ao RTLExpressions.

Figura 4.2: Rela¸c˜ao entre FlowNode, RegisterTransfer e RTLExpression.

Os RegisterTransfers servem tamb´em para identificar as opera¸c˜oes de fluxo de con- trolo. Para tal existem as seguintes classes: Jump, que representa uma opera¸c˜ao de salto incondicional e ´e o ´ultimo RegisterTransfer dos objectos do tipo RTLJumpNode; CondJump, que representa uma opera¸c˜ao de salto condicional e ´e o ´ultimo RegisterTransfer dos objec- tos do tipo RTLConditionalNode; Return, que representa uma opera¸c˜ao de retorno (de uma fun¸c˜ao) e ´e o ´ultimo RegisterTransfer dos objectos do tipo RTLReturnNode; e o Call, que representa uma invoca¸c˜ao de uma fun¸c˜ao/procedimento e ´e o pen´ultimo RegisterTransfer dos objectos do tipo RTLCallNode.

J´a vimos que o RTLS ´e gen´erico, ´e flex´ıvel (bastando para tal derivar novas classes) e possui alguma capacidade de abstrac¸c˜ao. Mas tamb´em ´e extens´ıvel, ali´as ´e extremamente extens´ıvel. O que se deve, n˜ao tanto ao modelo de RIC em si, mas mais `a pr´opria filosofia de implementa¸c˜ao do RTL System. ´E que as rotinas de an´alise e optimiza¸c˜ao (e outras), s˜ao implementadas como m´etodos das classes do RTLS. Nesta perspectiva ´e sempre poss´ı- vel acrescentar um novo m´etodo ou derivar uma nova classe que contenha novos m´etodos, incluindo algumas formas de an´alise que podem computar informa¸c˜ao, que n˜ao pertencendo directamente `a RIC est´a com esta relacionada. ´E l´ogico que o que est´a errado aqui, n˜ao ´e tanto o modelo de RIC, mas mais a pr´opria filosofia de desenvolvimento do RTL System, que n˜ao separa o que ´e a RIC, do que deveriam ser os componentes que operam sobre a RIC. Isto requer modificar as classes que s˜ao utilizadas para construir a RIC, sempre que se pretenda acrescentar ao sistema novas rotinas de compila¸c˜ao.

Este ´e o primeiro modelo apresentado que, para al´em de conter mais do que um n´ıvel de abstrac¸c˜ao (FlowNodes e RTLExpressions), disponibiliza tamb´em informa¸c˜ao que nor- malmente n˜ao est´a integrada na RIC, como ´e o caso do GDD. ´E como tal importante que garanta a consistˆencia entre os diversos n´ıveis de abstrac¸c˜ao e restantes estruturas de dados

4.2. Modelos de RIC: Estado da arte 51

integradas na RIC. Pois se tal n˜ao acontecer, caber´a ent˜ao ao utilizador assegurar essa con- sistˆencia, o que resulta numa sobrecarga de trabalhos que ´e obviamente indesej´avel. ´E claro que o RTLS possui tais mecanismos de consistˆencia, at´e porque a sua implementa¸c˜ao n˜ao ´e dif´ıcil quando se faz uso de uma linguagem orientada por objectos, como ´e o caso. Esses me- canismos permitem, por exemplo, a actualiza¸c˜ao autom´atica dos RegisterTransfer aquando da remo¸c˜ao de uma express˜ao; ou a actualiza¸c˜ao dos FlowNodes, aquando da remo¸c˜ao ou inser¸c˜ao de liga¸c˜oes entre nodos.

Para concluir falta determinar se a RTLS ´e ou n˜ao f´acil de utilizar, o que ´e um crit´erio que tem sempre alguma subjectividade. ´E claro que construir uma lista de tuplos ou uma lista de ´arvores de express˜oes ´e uma tarefa mais homog´enea, podendo como tal ser mais simples do que construir a RIC atrav´es do RTLS. Isto porque, por um lado, h´a mais do que um n´ıvel de abstrac¸c˜ao (a RIC ´e constru´ıda neste caso a dois n´ıveis diferentes); por outro lado existe todo um conjunto de informa¸c˜ao que ´e preciso apurar e preencher, que normalmente n˜ao existe nos modelos mais convencionais. ´E dif´ıcil negar que a constru¸c˜ao da RIC n˜ao ´e mais trabalhosa, mas este ´e o custo a pagar para que a implementa¸c˜ao das rotinas/componentes, que n˜ao os front-ends, seja mais acess´ıvel. Isto porque a RIC ´e semanticamente mais poderosa, disponibiliza outros recursos (nomeadamente diferentes n´ıveis de abstrac¸c˜ao), ´e flex´ıvel e gen´erica. Acresce ainda que potencia a implementa¸c˜ao de rotinas/componentes que s˜ao mais r´apidos a executar, dado que determinado tipo de informa¸c˜ao que em modelos mais convencionais teria que ser calculada, encontra-se neste caso j´a dispon´ıvel na pr´opria RIC (como ´e o caso do GFC e do GDD).