PROJETO DA ARQPON

Segundo Hennessy e Patterson (2007) (p. 9), existem três dimensões que devem orientar o projeto de uma arquitetura de computador:

• Arquitetura do conjunto de instruções (ISA): refere-se à interface de programação propriamente dita e a outros aspectos relevantes para a programação, tais como registradores internos, modos de endereçamento e tamanho das words.

• Organização microarquitetural: refere-se aos blocos arquiteturais (sistema de memória, unidades de processamento, topologia de interconexão) e como eles são organizados, em alto nível, para a execução das funcionalidades do computador.

• Hardware: refere-se aos detalhes específicos de implementação, tais como o

projeto da lógica em baixo nível e do encapsulamento do dispositivo.

O projeto da ARQPON v1.0 leva em consideração as duas primeiras dimensões, dado que a terceira diz respeito a uma implementação específica. Em particular, a implementação utilizada como protótipo para os experimentos relatados no Capítulo 4, denominada P2ON v1.0, é apresentada em detalhes no Apêndice A. Complementarmente a estas dimensões, faz- se útil elaborar um modelo lógico para a ARQPON, dado que este modelo pode ser utilizado para orientar a elaboração da ISA e da organização segundo os conceitos do PON.

As seções a seguir apresentam o projeto da ARQPON v1.0 levando em consideração as duas dimensões de projeto definidas e os modelos lógico e de programação complementares.

3.2.1 Modelo lógico

A Figura 24 apresenta o modelo lógico da ARQPON. As subseções a seguir descrevem este modelo do ponto de vista estrutural e dinâmico.

Figura 24 – Modelo lógico da ARQPON (Fonte: LINHARES; SIMÃO; STADZISZ, 2013)

3.2.1.1 Visão estrutural

Na Figura 24 as classes à esquerda (pacote Metamodelo PON) representam os elementos do metamodelo de notificações e as relações estruturais entre eles. Estes elementos são materializados, quando da implementação de software PON no nível de instrução da ARQPON, pelos elementos representados pelas classes ao centro (pacote Conjunto de

Instruções ARQPON). Estes elementos, por sua vez, estão estereotipados como “Instrução”,

em consonância com o requisito RIL-01 para a ARQPON (ver Seção 3.1.2), e apresentam ligações entre si que mapeiam os fluxos de notificação/atualização próprios do modelo de execução do PON. Deve-se perceber que os elementos Action, Instigation, Rule e FBE não são traduzidos em instruções porque, na prática, embora sejam elementos agregadores ou roteadores que compõem as abstrações de alto nível de um software PON baseado em regras,

Metamodelo PON

ARQPON <<hw>> Conjunto de instruções ARQPON

Attribute <<Elemento PON>> Premise <<Elemento PON>> Condition <<Elemento PON>> Rule <<Elemento PON>> Action <<Elemento PON>> Instigation <<Elemento PON>> Method <<Elemento PON>> 0..* 1..* 1..* FBE <<Elemento PON>> ConditionInstr <<Instrução>> PremiseInstr <<Instrução>> AttributeInstr <<Instrução>> MethodInstr <<Instrução>> Attribute repository <<memória>> Attribute Processor <<hw>> Premise Processor <<hw>> Condition Processor <<hw>> Method Processor <<hw>> P/C/M repository <<memória>>

Memory mapped IO interfaces

<<hw>> Scheduler/Conflict solver <<hw>> <<Attribute -> Premise>> <<Premise -> Condition>> <<Condition -> Method>> <<Atualização Attribute>> <<armazenado por>> <<processado por>> <<processado por>> <<processado por>> <<attribute update>> <<scan de atualização de Attribute>>

<<notif de Attribute>> 1..NPP <<notif de Premise>> 1..NCP <<notif de Condition>> 1..NMP <<controla>> <<recurso alocado por>>

<<controla>> <<recurso alocado por>>

<<controla>> <<recurso alocado por>>

<<atualização de Attribute>>

<<controle e atualização de saída>>

<<busca e atualização>>

von Neumann core

<<processador>> <<processado por>>

<<notifica>>

<<not if de Att ribute>>

<<notif de Premise>>

estes elementos não realizam qualquer tipo de operação, em tempo de execução, que justifique o seu mapeamento para instruções de baixo nível específicas.

As relações de dependência entre as classes do pacote Conjunto de Instruções

ARQPON e as classes do pacote ARQPON descrevem de que forma cada elemento do software PON de baixo nível (instrução PON) deve ser processado por uma implementação

da ARQPON. Ou seja, Premises, Conditions e Methods devem ser, dependendo de sua classe, processados por um conjunto de processos paralelos de hardware específicos dentro da implementação da ARQPON. Isto significa implementar um certo número de processadores responsáveis por executar processos de Premises (NPP), um certo número de processadores responsáveis por executar processos de Conditions (NCP) e um certo número de processadores responsáveis por executar processos de Methods (NMP). Tais processadores são representados na Figura 24 pelas classes Premise Processor, Condition Processor e

Method Processor, respectivamente, as quais estão estereotipadas como “hw”. Este modelo

atende ao requisito operacional RO-01.

Dado que as quantidades NPP, NCP e NMP de processos de hardware são finitas, a satisfação do requisito RO-03 é obtida por meio de um processo de hardware responsável por alocar recursos e escalonar a execução das instruções PON nos processos de hardware específicos para Premises, Conditions e Methods. Este processo, que é executado pelo

Scheduler/Conflict Solver apresentado na Figura 24, deve realizar o trabalho de alocação

levando em consideração cada uma das notificações que são trafegadas entre os diferentes processos de hardware, de tal maneira que possa verificar, via acesso ao repositório de

Premises, Conditions e Methods, quais são os elementos que devem ser alocados para

consumir a notificação em questão e alocá-los de fato.

A relação de extensão entre o núcleo von Neumann e o processador específico para processamento de Methods indica que uma aplicação PON pode ser logicamente implementada de forma híbrida. Ou seja, parte da funcionalidade desta aplicação seria implementada estritamente utilizando Methods PON, para execução pelo processo de

hardware responsável pelos Methods, e parte seria implementada utilizando funções segundo

o modelo de von Neumann, a serem executadas pelo núcleo von Neumann apresentado na figura.

3.2.1.2 Visão dinâmica

Do ponto de vista dinâmico, cada conjunto de processos de hardware processa o conjunto de elementos do PON que lhe compete e propaga múltiplas notificações simultaneamente para o conjunto de processos imediatamente abaixo na Figura 24, conforme o modelo do PON. Os processos de hardware responsáveis pela execução de Methods, adicionalmente, efetuam atualizações no repositório de Attributes quando instigados. Estas atualizações, quando resultam em alteração no valor de Attributes, geram novas notificações que são detectadas pelo processador de Attributes e propagadas para os processadores de

Premises, reiniciando um “ciclo” de notificações.

O hardware de E/S, descrito na Figura 24 como Memory Mapped IO Interfaces, pode ser acessado e controlado pelos processos de hardware responsáveis pelos Methods. Além disso, o hardware de E/S pode ser configurado para efetuar atualizações no repositório de Attributes em função de novos dados de entrada, iniciando um novo ciclo de notificações conforme já explanado.

Cada conjunto de notificações é também repassado ao Scheduler/Conflict solver, o qual utiliza esta informação para tomar decisões sobre alocação e desalocação, bem como para implementar o algoritmo de resolução de conflitos e habilitar ou bloquear a execução dos processos sendo notificados em função desta resolução. Em particular, a alocação de elementos aos processos é disparada pela detecção, por parte do Scheduler/Conflict Solver, de uma notificação para um ou mais destinatários que não estão alocados a nenhum processo de

hardware. Cabe, então, ao Scheduler/Conflict solver obter os elemento(s) destinatário(s) da

notificação no repositório de P/C/M, alocar este(s) elemento(s) no(s) processo(s) selecionado(s) e replicá-la somente a este(s) elemento(s), dado que os demais elementos, que já estavam alocados previamente a processos de hardware, já teriam tido a oportunidade de consumir esta notificação.

O Scheduler/Conflict solver pode, ainda, notificar o núcleo von Neumann da necessidade de execução de uma função implementada segundo o modelo de von Neumann. Ao executar esta função o núcleo von Neumann pode acessar e/ou alterar valores de

Attributes, de forma semelhante aos demais processadores de Methods, eventualmente

3.2.2 Considerações iniciais sobre o modelo de programação

Conforme apresentado na Figura 24, propõe-se que cada Premise, Condition e

Method do software PON a ser executado na implementação da ARQPON seja mapeado para

uma instrução. Portanto, a definição da ISA deve levar em consideração esta categorização e os dados requeridos para a descrição de cada um dos elementos do PON citados na forma de instrução (ver Seção 3.2.4).

Do ponto de vista de fluxo de controle, o PON é fundamentalmente diferente de outros modelos de execução tais como von Neumann e fluxo de dados. Enquanto em um programa von Neumann o fluxo de controle é ditado pela evolução do valor do contador de programa e em um programa de fluxo de dados o fluxo de controle é ditado pela disponibilidade dos dados para execução das instruções, em um programa PON o fluxo de controle é ditado pela propagação de notificações de alteração de Attributes e consequentes alterações dos valores de Premises e Conditions a eles associadas. Sendo assim, dado que o fluxo de controle PON é dependente do correto mapeamento das dependências de notificação entre os elementos, conclui-se que as instruções da ISA da ARQPON devem definir explicitamente este mapeamento.

Do ponto de vista de fluxo de dados, programas von Neumann acessam dados em posições de memória, calculadas estaticamente ou dinamicamente caso alguma informação de escopo ou contexto seja necessária para localização dos dados (caso do uso de variáveis automáticas de função ou atributos de objeto, por exemplo). Já programas puramente de fluxo de dados não definem o conceito de variáveis da mesma forma que os programas von Neumann, visto que os dados são produzidos pela execução das instruções e imediatamente repassados e consumidos como parâmetros para execução de outras instruções que deles dependem.

Programas PON, por sua vez, definem Attributes que representam o estado dos FBEs e, portanto, dependem de uma implementação que armazene esta informação de estado na forma de variáveis que não sejam desalocadas ou consumidas. Sendo assim, faz-se necessário reservar espaço em memória para armazenamento dos dados associados a um Attribute. Além disso, Attributes também fazem parte da cadeia de notificações do PON e, portanto, são elementos ativos que possuem ligações com outros elementos (Premises) e algumas propriedades que influenciam no seu comportamento lógico (p. ex. ser impertinente, exclusivo ou determinístico). Isto requer que todas estas informações também sejam

mapeadas em uma ou mais instruções específicas, a serem executadas pelo processo de

hardware responsável pelos Attributes (ver Figura 24).

Para interagir com dispositivos de E/S, a ARQPON pode definir o mapeamento de registradores em memória. Isto facilita a definição dos Methods, dado que estes podem tratar da escrita/leitura de valores dos dispositivos periféricos da mesma forma como tratam escritas/leituras de Attributes, porém sem necessariamente disparar o fluxo de notificações da aplicação.

Feitas estas considerações, pode-se categorizar o modelo de programação da ARQPON como um novo modelo de execução do PON que (como o próprio PON) reaproveita algumas características do modelo imperativo e do modelo declarativo, pelas seguintes razões:

• As instruções propostas são imperativas no sentido de que descrevem “o que” fazer de forma assertiva, quando do recebimento de notificação pelo elemento que é descrito por aquela instrução.

• As instruções propostas também são declarativas justamente por serem mapeáveis diretamente para os elementos da cadeia de notificações, descrevendo a sua estrutura e/ou seu comportamento lógico e as relações que eles apresentam com os demais elementos (descrição do fluxo de controle).

A Seção 3.2.4 descreve detalhadamente a ISA proposta para a ARQPON v1.0, levando em consideração todos os detalhes do modelo de programação abordados anteriormente. Na Seção 3.2.3 a seguir, por sua vez, são abordados outros aspectos arquiteturais relevantes, relacionados à fundamentação teórica apresentada no Capítulo 2 e que servem como orientação para o detalhamento da ARQPON v1.0.

3.2.3 Aspectos arquiteturais relevantes

3.2.3.1 Processador de granularidade fina

O modelo de execução definido pelo PON implica a propagação potencialmente paralela de notificações entre os elementos da cadeia que são conectados para a implementação da lógica causal (Attributes, Premises, Conditions, Actions, Instigations e

cadeia de notificações estejam alocadas para os processos de hardware respectivos e executando suas operações de forma simultânea e independente.

O paralelismo potencial de uma aplicação PON é melhor explorado quanto maior for o número de diferentes operações prontas para execução que possam ser imediatamente executadas sem necessitar compartilhar o recurso de processamento com outras operações. Para tanto, parte-se do princípio de que cada elemento da cadeia de notificações do PON pode ter seu comportamento executado por uma unidade de processamento específica (representada por um processo de hardware conforme o modelo lógico apresentado na Figura 24). Esta unidade é exclusivamente alocada para execução desta tarefa, porém passível de realocação (efetuada pelo processo Scheduler/Conflict solver, também apresentado na Figura 24) para a execução do comportamento de outros elementos conforme seja necessário.

Considerando-se esta alocação exclusiva, requer-se um baixo grau de complexidade de cada unidade de processamento, dado o baixo grau de complexidade das operações executadas pelos elementos da cadeia do PON quando consideradas individualmente. De fato,

Premises executam operações relacionais simples, Conditions executam operações lógicas

simples e Actions e Instigations são simplesmente elementos propagadores de notificação. Em relação aos Methods, estes podem executar lógicas complexas (iterações, por exemplo), porém ainda assim é possível desenvolver aplicações PON nas quais aquelas lógicas sejam decompostas em operações mais simples. Uma vez estabelecida a operação mínima que deve ser executada por um método PON (“método mínimo”), pode-se projetar o elemento de processamento de métodos de tal maneira que este seja simples o suficiente para somente executar a operação mínima, a qual é apresentada na Seção 3.2.3.4.

A implementação de múltiplas unidades básicas de processamento é uma estratégia que tem sido levada em consideração no que diz respeito à evolução das arquiteturas de computadores paralelos. Segundo Kogge et al (2008), aplicações que demandem alto desempenho (p. ex., sistemas de manipulação de grandes quantidades de dados) podem necessitar de hardware que suporte a execução de até bilhões de threads em paralelo. Ainda, Kogge et al (2008) mencionam que esta multiplicidade demanda modelos de programação adequados (sem propor nenhum especificamente), no que se pode enquadrar então os fundamentos do PON aplicados à ARQPON conforme discorrido anteriormente. Por sua vez, Asanovic et al (2006) argumentam que simplificar as unidades básicas de processamento pode facilitar o seu projeto e também a sua verificação funcional, além do que pipelines de unidades de processamento mais complexas acarretam custos em termos de dissipação de energia que nem sempre compensam os ganhos teóricos em desempenho.

Dado que as operações das Premises, das Conditions e dos Methods são executadas por múltiplas unidades de processamento, alocadas exclusivamente para execução de uma destas operações por vez e que cada uma destas operações individualmente é de baixa complexidade, conclui-se que faz sentido especializar as unidades de processamento em função do tipo de operação. Esta especialização objetiva aproveitar melhor os recursos de

hardware disponíveis, pois permite que estes recursos sejam alocados em um número maior

de unidades de processamento de implementação relativamente mais simples em hardware. Segundo Ungerer, Robic e Silc (2003), núcleos de implementações do tipo interleaved

multithreading (IMT), que executam instruções de várias threads de maneira intercalada,

tendem a ser mais simples porque nestes núcleos não é necessário hardware específico para a detecção de conflitos em pipeline (não existe exploração de ILP pois duas instruções consecutivas de uma mesma thread nunca estão em execução simultânea no pipeline). Embora não sejam implementações de IMT, os núcleos propostos para execução de Premises,

Conditions e Methods também apresentam a propriedade de não necessitar detecção de

conflitos em pipeline, visto que a própria estrutura do software PON implica que cada um destes núcleos execute uma operação por vez, excitada por uma notificação recebida conforme a dinâmica da cadeia de notificações.

Para a especialização das unidades de processamento da ARQPON define-se a seguinte terminologia:

• PP (Premise Processor ou Processador de Premissa): unidade de processamento responsável por efetuar o cálculo lógico de uma operação relacional envolvendo os valores de um ou dois Attributes

• CP (Condition Processor ou Processador de Condição): unidade de processamento responsável por efetuar o cálculo lógico de uma operação lógica envolvendo os valores lógicos de duas Premises ou SubConditions.

• MP (Method Processor ou Processador de Método): unidade de processamento responsável por executar a operação mínima executável por um método PON em resposta a um valor lógico verdadeiro notificado por uma Condition (ver Seção 3.2.3.4 para mais detalhes).

Partindo-se desta terminologia, a implementação física dos conjuntos de processos de

hardware utilizados para processamento das Premises, Conditions e Methods (Figura 24) é

Em função das características citadas de execução independente, com alto grau de paralelismo e, ao mesmo tempo, heterogênea no sentido de se constituir de diferentes tipos de operação (avaliações relacionais, lógicas e/ou atualizações de atributos), pode-se classificar esta proposta para a ARQPON como uma proposta de arquitetura com granularidade de paralelismo fina (TANENBAUM, 2013). Ou seja, o processador construído segundo a ARQPON deve ser composto por muitos elementos de processamento relativamente simples, eventualmente com baixo poder de processamento e interagindo por meio de comunicação de relativamente alta velocidade. A seção a seguir discorre sobre a questão de comunicação/interconexão entre as múltiplas unidades de processamento.

3.2.3.2 Topologia de interconexão

Por ser proposta na forma de uma arquitetura multiprocessada, a ARQPON deve definir uma topologia de interconexão entre as diversas unidades de processamento que a compõem.

O modelo lógico de execução orientada a notificações do PON implica a propagação de resultados do cálculo de Premises para parâmetros de Conditions, bem como a avaliação de resultados dos cálculos de Conditions para a consequente ativação de Methods. Sendo assim, pode-se afirmar que existem, logicamente, camadas de interconexão entre Premises e

Conditions e entre Conditions e Methods, as quais são apresentadas no modelo lógico da

Figura 24 na forma de links portadores de notificações entre os conjuntos de processos de

hardware relacionados a Premises, Conditions e Methods, conforme o requisito operacional

RO-02.

Em função desta característica, propõe-se, para a ARQPON v1.0, a definição de camadas físicas de interconexão hierárquicas distintas entre os grupos de PP e CP e entre os grupos de CP e MP que implementam fisicamente o modelo lógico de processos de hardware. A Figura 25 demonstra este aspecto da arquitetura.

Dado o comportamento desejado de realocação de unidades de processamento para diferentes elementos da cadeia em tempo de execução (p. ex. poder realocar um determinado CP para diversas Conditions da aplicação PON à medida que for necessário, em atendimento ao requisito operacional RO-03), é necessário que a implementação física da camada de interconexão suporte roteamento dinâmico entre PP e CP e entre CP e MP. Além disso, segundo o metamodelo da cadeia de notificações do PON, cada Premise pode potencialmente

notificar N Conditions que dela dependem, e cada Condition pode potencialmente notificar a execução de N Methods (por meio do mapeamento via Instigations), portanto é necessário que