quarta-feira, 2 de novembro de 2016

Nova Ordem Mundial - Projeto Base - Criação de Moeda Digital Única - Evite Fracassos Com a Transformação Digital - Manual Estratégico, Tático, Técnico, Tecnológico, Jurídico Digital, Operacional e Introdutório do Processamento Geométrico Quântico nº 01 - PARTE 05








ILMO SENHOR OFICIAL DO 1º OFÍCIO DO REGISTRO CIVIL, TÍTULOS E DOCUMENTOS E PESSOAS JURÍDICAS DE BRASÍLIA-DF (CARTÓRIO MARCELO RIBAS)


Setor Comercial Sul-SCS, Quadra 08, Bloco B-60, Sala 140-E, 1º andar, Edifício Venâncio 2000



Brasília-DF - CEP 70.333-900

Fone - (61) 3224-4026



REFERÊNCIA - Módulo 03/33 - Nova Ordem Mundial - Moeda Digital Única - Processamento de Informações Por Meio de Entrelaçamento Quântico de Partículas - Manual Estratégico, Tático, Técnico, Tecnológico, Jurídico Digital, Operacional e Introdutório do Processamento Geométrico Quântico nº 01


Eu, Rogerounielo Rounielo de França, brasileiro, casado, OAB-SP 117.597, residente e domiciliado em Águas Claras, Distrito Federal, Brasil, solicito a Vossa Senhoria o registro do projeto, citado em epígrafe, constante, do anexo nº 01, que é de arquitetura aberta, podendo ser divulgado e/ou utilizado, eternamente, apenas, GRATUITAMENTE, por qualquer pessoa física ou jurídica, no Brasil e no mundo, e ALTERADO POR QUALQUER USUÁRIO, sem prévia autorização do proprietário dos direitos intelectuais dessas ideias, CONCEBIDAS PARA BENEFICIAR A HUMANIDADE, RECEBIDAS, PELO REQUERENTE, POR INTERMÉDIO DE “MEDIUNIDADE INTUITIVA”, DE TERCEIRO GRAU.


Atenciosamente,


Brasília-DF, 02 de Setembro de 2016


_____________________________
Rogerounielo Rounielo de França


Anexos: 01/501



  


===============================================================
Anexo nº 01 - Módulo 03/33 - Nova Ordem Mundial - Moeda Digital Única - Processamento de Informações Por Meio de Entrelaçamento Quântico de Partículas - Manual Estratégico, Tático, Técnico, Tecnológico, Jurídico Digital, Operacional e Introdutório do Processamento Geométrico Quântico nº 01
===============================================================

DESTINATÁRIOS: ORGANIZAÇÕES PÚBLICAS, ORGANIZAÇÕES PRIVADAS E CIDADÃOS DO BRASIL E DO MUNDO

Evite fracassos com a transformação digital da sua organização e do seu país para a economia digital


CONTINUAÇÃO DA PARTE 04

11.4.2.13.1     Antes de prosseguirmos é necessário analisar como funciona a lógica da programação, quais as dificuldades que serão encontradas para fazer diferentes “Redes de Relacionamentos Virtuais” e diferentes “Ecossistemas de Relacionamentos Virtuais” operarem entre si, dado que as respectivas arquiteturas dos processadores (Vide “Arquitetura A” e “Arquitetura B”, abaixo) e da própria linguagem de programação e de máquina poderem ser diferentes entre si, por exemplo, o que inviabilizaria da troca de informações entre a “Rede de Relacionamento Virtual nº 01” e o “Ecossistema de Relacionamento Virtual nº 01”, e quais seriam eventuais alternativas de solução para superar essas dificuldades:


11.4.2.13.2     A lista de arquiteturas de processadores, extraída do link https://pt.wikipedia.org/wiki/Lista_de_arquiteturas_de_processadores, é: Intel, AMD64, Alpha, i386, i486, Macintosh, Arm, Sparc, PowerPC, Hppa, ia64, m68k, mips, mipsel, s390 e SuperH.

11.4.2.13.3     A “Arquitetura A” é utilizada na “Rede de Relacionamento Virtual nº 01” e no “Ecossistema de Relacionamento Virtual nº 01”, ambas utilizando o “Processador nº 01”.

11.4.2.13.4     A “Arquitetura B” é utilizada na “Rede de Relacionamento Virtual nº 02” e no “Ecossistema de Relacionamento Virtual nº 02”, ambas utilizando o “Processador nº 02”.

11.4.2.13.5     As duas instruções acima orientam o “Processador nº 01” e o “Processador nº 02” que o valor do registrador nº 1 deve ser adicionado ao valor do registrador nº 2 e que o resultado deve ser armazenado no registrador nº 3, mas como as sequências binárias dessas instruções no “Processador nº 01” e no “Processador nº 02” são diferentes não é possível que a “Rede de Relacionamento Virtual nº 01” e o “Ecossistema de Relacionamento Virtual nº 01”, que utiliza a “Arquitetura A” seja conectada a “Rede de Relacionamento Virtual nº 02” e o “Ecossistema de Relacionamento Virtual nº 02”, que utiliza a “Arquitetura B”, situação que é um grande obstáculo para que organizações diferentes criem ambientes virtuais, conjuntos, interoperáveis, intercomunicáveis e intercambiáveis, com vistas à unificada da infra-estrutura tecnológica e de rede voltada para as “Experiências Eletrônicas” de “Clientes Digitais”, sem ter que criar e manter a “Arquitetura A” e a “Arquitetura B”.

11.4.2.13.6     Iniciaremos nossa análise definindo, em linhas gerais, o que é um computador, que possui três elementos básicos:

MEMÓRIA RAM

11.4.2.13.7     Armazena dados de programas em execução, quando o computador está ligado. Não armazena conteúdos permanentes. Dados são perdidos quando o computador é desligado. Os programas, armazenados no HD, são copiados do disco rígido ou HD para a memória RAM, quando o usuário deseja executar alguma tarefa:



DISCO RÍGIDO ou HD

11.4.2.13.8     Armazenamento de dados. Conteúdo não é descartado quando o computador é desligado:



CPU (REGISTRADORES + ULA + UC)

11.4.2.13.9     A CPU só executa instruções em linguagem de máquina, sendo composta pela Unidade de Controle-UC, Unidade Lógica e Aritmética-ULA e Registradores (guardam dados e resultados). A CPU controla as alterações e o funcionamento do computador, executando cálculos, decisões lógicas e instruções:




11.4.2.13.10         Vistos quais são os elementos, partes integrantes, funcionamento das partes integrantes e funcionalidades principais das partes integrantes de um computador, como ocorre o processo para que os usuários insiram dados nos computadores para serem processados?

11.4.2.13.11         É quase inviável inserir dados, diretamente, nos computadores, utilizando linguagem de máquina, mas, além disso, os dados não podem ser inseridos de qualquer forma nos computadores.

11.4.2.13.12         Para inserir dados nos computadores existe uma técnica, que é a técnica da lógica de programação, por intermédio da qual são criadas sequências lógicas para serem processadas pelo computador.

11.4.2.13.13         Antes de analisarmos o que é uma sequência lógica, o que é lógica?

Início da transcrição

Lógica é um substantivo feminino com origem no termo grego logiké, relacionado com o logos, razão, palavra ou discurso, que significa a ciência do raciocínio.

Em sentido figurado, a palavra lógica está relacionada com um maneira específica de raciocinar, de forma acertada.


Final da transcrição

11.4.2.13.14         Pode-se dizer que uma sequência lógica é uma “sequência finita de regras, raciocínios ou operações que, aplicada a um número finito de dados, permite solucionar classes semelhantes de problemas” ou “conjunto das regras e procedimentos lógicos perfeitamente definidos que levam à solução de um problema em um número finito de etapas” (Fonte - Link https://www.google.com.br/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=algoritmo), conceito muito próximo ao de algoritmo.

11.4.2.13.15         Algoritmo é uma sequência finita de instruções bem definidas e não ambíguas, cada uma das quais devendo ser executadas mecânica ou eletronicamente em um intervalo de tempo finito e com uma quantidade de esforço finita” (Fonte - Link https://pt.wikipedia.org/wiki/Algoritmo).

11.4.2.13.16         Portanto, pode-se dizer, em linhas gerais, que sequência lógica “é uma sequência finita de instruções bem definidas e não ambíguas, cada uma das quais devendo ser executadas mecânica ou eletronicamente em um intervalo de tempo finito e com uma quantidade de esforço finita”.

11.4.2.13.17         O programador cria várias sequências lógicas, utilizando interface de programação como, por exemplo, “Sequëncia Lógica nº 01”, “Sequëncia Lógica nº 02”, “Sequëncia Lógica nº 03”, “Sequëncia Lógica nº 04”, “Sequëncia Lógica nº N”.

11.4.2.13.18         O encadeamento de referidas sequências lógicas cria um programa ou software (conjunto de sequências lógicas para serem processadas pelo computador).

11.4.2.13.19         Entretanto, o computador não processa o software, diretamente, pois somente é capaz de processar as informações em linguagem de máquina.

11.4.2.13.20         Um programa em código de máquina consiste de uma sequência de zeros e de uns, que significam uma sequência de instruções a serem executadas pelo computador, conforme figura a seguir:


11.4.2.13.21         Os programas de computador raramente são criados em linguagem de máquina, mas devem ser traduzidos (por compiladores) para serem executados diretamente pelo computador” (Fonte - Link https://pt.wikipedia.org/wiki/C%C3%B3digo_de_m%C3%A1quina), conforme figura a seguir:


Princípios de um compilador - O que é um compilador?



11.4.2.13.22         Um compilador é um programa de computador (ou um grupo de programas) que, a partir de um código fonte escrito em uma linguagem compilada, cria um programa semanticamente equivalente, porém escrito em outra linguagem, código objeto.[1] Classicamente, um compilador traduz um programa de uma linguagem textual facilmente entendida por um ser humano para uma linguagem de máquina, específica para um processador e sistema operacional” (Fonte - Link https://pt.wikipedia.org/wiki/Compilador).

11.4.2.13.23         O código fonte são as várias sequências lógicas, criadas pelo programador, utilizando interface de programação, como, por exemplo, “Sequëncia Lógica nº 01”, “Sequëncia Lógica nº 02”, “Sequëncia Lógica nº 03”, “Sequëncia Lógica nº 04”, “Sequëncia Lógica nº N”.

11.4.2.13.24         O código fonte, depois de criado, é transformado para linguagem de máquina, por um compilador, utilizando linguagem específica (Assembly ou linguagem de montagem), descrita a seguir:

Início da transcrição

Assembly ou linguagem de montagem é uma notação legível por humanos para o código de máquina que uma arquitetura de computador específica usa, utilizada para programar dispositivos computacionais, como microprocessadores e microcontroladores. A linguagem de máquina, que é um mero padrão de bits, torna-se legível pela substituição dos valores em bruto por símbolos chamados mnemónicos[1] [2] .

Por exemplo, enquanto um computador sabe o que a instrução-máquina IA-21 (10110000 01100001) faz, para os programadores é mais fácil recordar a representação equivalente em instruções mnemónicas MOV AL, 61h. Tal instrução ordena que o valor hexadecimal 61 (97, em decimal) seja movido para o registrador 'AL'.”

A conversão da linguagem de montagem para o código de máquina é feita pelo montador ou assembler, que é basicamente um tradutor de comandos, sendo mais simples que um compilador.


Final da transcrição

11.4.2.13.25         Compiladores

Início da transcrição

Princípios de Um Compilador


Neste artigo apresentarei um assunto muito relevante (e que a maioria dos desenvolvedores de software não dá a devida atenção), que são os compiladores e seu funcionamento. Falaremos sobre o funcionamento e aplicação dos compiladores, sobre a ótica da implementação e conceito, pois em sua forma mais geral, um compilador é um programa que aceita como entrada um texto de programa em uma certa linguagem e produz como saída um texto de programa em outra linguagem, enquanto preserva o significado desse texto.

Podemos entender da seguinte forma: que esse processo é chamado tradução como seria denominado se os textos estivessem em linguagens naturais. Quase todos os compiladores fazem a tradução de uma linguagem de entrada, a linguagem de origem ou linguagem-fonte, apenas para uma linguagem de saída, a linguagem de destino.

Este conceito acima pode ser extrapolado para outros tipos de sistemas além do próprio compilador, como por exemplo, sistemas de gestão de regras de negócio, quando se precisa escrever regras em linguagem de alto nível sem se ter o inconveniente de compilar o programa novamente. Normalmente, espera-se que a linguagem de origem e a linguagem de destino sejam bem diferentes: por exemplo, a linguagem de origem poderia ser C e a linguagem de destino poderia ser código de máquina para processador especificamente da série Pentium (não é comum, mas é possível ser feito).

O nome “compilador” é usado principalmente para os programas que traduzem o código fonte de uma linguagem de programação de alto nível para uma linguagem de programação de baixo nível (por exemplo, Assembly ou código de máquina).

Tenha em mente que a principal razão pela qual alguém desejaria tal tradução é o fato de haver hardware no qual seria possível “executar” o programa traduzido ou, mais corretamente falando, fazer o hardware executar as ações descritas pela semântica do programa. Este conceito é bastante importante quando se precisa manipular um hardware específico. O hardware é a única fonte real de poder de computação.

A execução de um programa traduzido muitas vezes envolve alimenta-lo com dados de entrada em algum formato, e isso provavelmente resultará em alguns dados de saída em algum outro formato. Os dados de entrada podem ser oriundos de diversas fontes: os exemplos são arquivos, sequências de teclas digitadas e pacotes de rede. Da mesma forma, a saída pode ir para diversos lugares; os exemplos são arquivos, telas de monitores e impressoras.

É importante observar que para obter o programa traduzido executamos um compilador, que é simplesmente outro programa cujos dados de entrada são constituídos por um arquivo com o formato de um texto de origem de programa e cujos dados de saída constituem um arquivo com o formato de código executável (para um determinado sistema operacional).

Observe que para obter o compilador, executamos outro compilador cuja entrada consiste em código-texto-fonte do compilador e que produzirá código executável correspondente a esse código-texto-fonte, como faria para o código-texto-fonte de qualquer programa.

Abaixo, segue uma imagem para ilustrar o que foi falado até o momento:


Perceba que um aspecto claro da compilação é que a entrada tem uma propriedade chamada semântica (seu ‘significado’), que deve ser preservado pelo processo e com frequência é menos claramente identificável em um programa de conversão de arquivos tradicional, por exemplo um programa que faça a conversão de EBCDIC em ASCII.

O Compilador consegue realizar suas tarefas devido a dois fatores:

A entrada está em uma linguagem e consequentemente tem uma estrutura, que é descrita no manual de referência da linguagem.

A semântica da entrada é descrita em termos dessa estrutura e está associada a ela.

Esses fatores permitem ao compilador ‘reconhecer’ o programa e coletar sua semântica em uma representação semântica.

Outro conceito importante é: A parte de um compilador que executa a análise do texto da linguagem-fonte é chamada front-end, e a parte que faz a síntese da linguagem de destino é o back-end.


Um ponto importante sobre a imagem acima (e que você pode estar se perguntando) é que a imagem acima sugere de imediato outro modo de operação para um compilador: se todos os dados de entrada exigidos estivessem disponíveis, o compilador poderia executar as ações especificadas pela representação semântica, em vez de expressa-las novamente em uma forma distinta. Certo? Sim.

Mas nesta abordagem, o back-end de geração de código é então substituído por um back-end de interpretação, e assim, o programa inteiro é chamado interpretador e não compilador. Um ponto positivo para os interpretadores é que normalmente ele é escrito em uma linguagem de alto nível, e portanto funcionará na maioria dos tipos de máquinas, enquanto o código-objeto gerado só funcionará em máquinas do tipo de destino: em outras palavras, a portabilidade será aumentada. Outra razão é que a escrita de um interpretador é muito menos trabalhosa que a escrita de um back-end (sem a menor dúvida).

É importante observar que não há nenhuma diferença fundamental entre usar um compilador e usar um interpretador. Em ambos os casos, o texto do programa é processado em uma forma intermediária, a qual é então interpretada por algum mecanismo de interpretação.

Na compilação: O processamento de programas é considerável, a forma intermediária resultante, código binário executável específico da máquina, é de baixo nível e o mecanismo de interpretação é a CPU do hardware. A execução do programa é relativamente rápida.

Na interpretação: O processamento de programas é de mínimo a moderado, a forma intermediária resultante, alguma estrutura de dados específica do sistema, é de nível alto a médio, o mecanismo de interpretação é um programa (de software). A execução de programas é relativamente lenta.

Por Que Se Chama Compilador?

Então vamos aos conceitos: O significado original de compilar é selecionar material representativo e acrescenta-lo a uma coleção.  Em seu início, a conversão de linguagens de programação era vista do mesmo modo: por exemplo, quando a entrada continha ‘a + b’, um fragmento de código pré-fabricado ‘carregar a no registrador; adicionar b ao registrador’ era selecionado e adicionado à saída. Observe que um compilador compilava uma lista de fragmentos de código a serem adicionados ao programa traduzido. Os compiladores de hoje, em especial aqueles relacionados a paradigmas de programação não-imperativos, com frequência realizam transformações muito mais radicais sobre o programa de entrada.

Por Que Devo Estudar Compiladores?

Há uma série de razões objetivas pelas quais o estudo da construção de compiladores é uma boa ideia: A construção de compiladores é um ramo muito bem-sucedido da ciência da computação, e um dos primeiros a obter esse atributo. Dada sua relação próxima com a conversão de arquivos, ela tem uma aplicação mais ampla que os simples compiladores. Contém muitos algoritmos geralmente úteis em uma configuração realista.

A principal razão subjetiva para estudar a construção de compiladores é, a pura curiosidade: é fascinante ver como os compiladores conseguem realizar tudo que fazem. E principalmente ganhar mais conhecimentos em algoritmos mais complexos.

A construção de compiladores é um ramo muito bem-sucedido da ciência da computação. Algumas razões para isso são a estruturação apropriada do problema, o uso criterioso de formalismos e o uso de ferramentas sempre que possível.

Os compiladores analisam sua entrada, constroem uma representação semântica e sintetizam sua saída a partir dela. Esse paradigma de análise-síntese é muito eficiente e amplamente aplicável.

Veja por exemplo, um programa para medir comprimentos de palavras em um texto poderia consistir em um front-end que analisasse o texto e construísse interiormente uma tabela de pares (comprimento, frequência) e um back-end que depois imprimisse essa tabela.

Outro fato importante de ser apresentado, é que, sem a separação estrita das fases e análise e síntese, as linguagens de programação e a construção de compiladores não seriam o que são hoje.

Sem ela, cada nova linguagem exigiria um conjunto completamente novo de compiladores para todas as máquinas. Esse fato dificultaria muito todo o processo. Basta um novo front-end para essa linguagem, a ser combinado com os back-ends existentes para as máquinas atuais.

Veja conforme a imagem abaixo o que estamos falando:



Observe porém, que essa separação estrita não é completamente livre de trabalho. Se um front-end souber que está fazendo a análise para uma máquina com instruções de máquina especiais referentes a saltos de vários caminhos, é provável que ele analise instruções case/switch de modo que elas possam se beneficiar dessas instruções de máquina.

De forma parecida, se um back-end souber que está gerando código para uma linguagem que não tem nenhuma declaração de rotinas aninhadas, ele poderá gerar um código mais simples para chamadas de rotinas.

Entenda que muitos compiladores profissionais são compiladores integrados, destinados a uma linguagem de programação e uma arquitetura de máquina, utilizando uma representação semântica que deriva da linguagem-fonte e que já deve conter elementos da máquina de destino.

De qualquer forma, a estruturação desempenhou e ainda desempenha um papel importante na introdução rápida de novas linguagens e novas máquinas.

Outro fato que deve ser sempre levado em conta é o uso criterioso de formalismos. Em algumas partes da construção de compiladores foram desenvolvidos excelentes formalismos padronizados, os quais reduzem bastante o esforço para produzir essas partes.

Os melhores exemplos são expressões regulares e gramáticas livres de contexto, usadas em análise léxica e sintática. Não entraremos nesses detalhes aqui, pois demandaria um curso inteiro sobre o assunto. As gramáticas de atributos são um formalismo que pode ser usado para tratar o contexto, as relações de longa distância em um programa que vincula, por exemplo, o uso de uma variável à sua declaração.

A geração de código-objeto para uma dada máquina envolve uma grande quantidade de programação complicada quando feita manualmente, mas o processo pode ser automatizado usando-se, por exemplo, técnicas de correspondência de padrões e programação dinâmica.

Diversos formatos de formalismos foram projetados para a descrição de código de máquina tanto em nível “Assembly” quando em nível binário, todavia nenhum deles obteve ampla aceitação até hoje, e cada sistema de escrita de compiladores tem sua própria versão.

Teoricamente, assim que se tenha o formalismo apropriado no qual será descrito o que um determinado programa deve fazer, pode-se gerar um programa a partir desse formalismo, usando um gerador de programas.

Observe que para o ramo de compiladores, gerar programas em vez de escreve-los à mão tem várias vantagens:

A entrada para um gerador de programas é de um nível de abstração muito mais alto do que seria o programa escrito à mão. O programador precisa especificar menos, e as ferramentas assumem a responsabilidade por grande parte das tarefas de administração interna propensas a erros. Isso aumenta as chances de que o programa esteja correto. Por exemplo, seria incômodo escrever tabelas de análise à mão.

O uso de ferramentas de geração de programas oferece maior flexibilidade e facilidade de modificação. Por exemplo, se durante a fase de projeto de uma linguagem fosse considerada uma pequena mudança na sintaxe, um analisador escrito à mão seria um grande empecilho a qualquer mudança. Com um analisador gerado, bastaria alterar a descrição da sintaxe e gerar um novo analisador.

Pode-se adicionar código pronto ou sob medida ao programa gerado, aumentando sua capacidade quase sem custo. Por exemplo, o tratamento de erros de entrada em geral é uma tarefa difícil em analisadores escritos à mão; um analisador gerado pode incluir código pronto de correção de erros sem qualquer esforço por parte do programador.

Uma descrição formal às vezes pode ser usada para gerar mais de um tipo de programa. Por exemplo, depois de termos escrito uma gramática para uma linguagem com o propósito de gerar um analisador a partir dela, podemos usa-la para gerar um editor dirigido para a sintaxe, um editor de textos de programa de uso especial que oriente e forneça suporte para o usuário durante a edição de programas nessa linguagem.

Na teoria, os programas gerados podem ser ligeiramente mais ou menos eficientes que programas escritos à mão, mas gera-los é tão mais eficiente que escreve-los à mão que, sempre que existir essa possibilidade, quase sempre será preferível gerar um programa. Outras formas de programação podem ser consideradas construção de compiladores, mais do que se consideraria tradicionalmente. Os exemplos são a leitura de dados estruturados, a introdução rápida de novos formatos e os problemas gerais de conversão de arquivos.

A estrutura básica de qualquer compilador tem de conter pelo menos um analisador léxico, um analisador de sintaxe e um tratador de contexto, nessa ordem. Isso nos leva à estrutura do compilador/interpretador mostrado abaixo.


O back-end permite duas implementações intuitivamente diferentes: um gerador de código e um interpretador. Ambos usam o código intermediário, o primeiro para gerar código de máquina, e o segundo para executar de imediato as ações implícitas.

A imagem anterior mostra que, para descrever o compilador mínimo, tínhamos de decompor o front-end em três módulos e que o back-end poderia permanecer como um único modulo.

E claro que isso não é suficiente para um compilador real. Apresento uma versão mais realista abaixo, no qual o fronr-end e o back-end consistem cada um em cinco módulos. Além desses módulos, compilador conterá módulos para o tratamento da tabela de símbolos e relatórios de erros; esses módulos serão chamados por quase todos os outros módulos.


Propriedades Para Bom Compilador

Não preciso nem dizer que a propriedade mais importante de um bom compilador é a de gerar código correto (mas já disse). Um compilador que ocasionalmente gera código incorreto é inútil; um compilador que gera código incorreto uma vez por ano pode parecer útil, mas talvez seja perigoso. Também é importante que um compilador obedeça completamente à especificação da linguagem.

Ele pode estar tentando implementar um subconjunto, um superconjunto, ou até aquilo que às vezes é chamado sarcasticamente um ‘subconjunto’ estendido da linguagem, e os usuários podem até agradecer, mas esses mesmos usuários logo perceberão que programas desenvolvidos com um tal compilador são muito menos portáteis que programas escritos com o uso de um compilador completamente compatível.

Outra propriedade de um bom compilador, negligenciada com frequência, é que ele deve ser capaz de manipular programas de tamanho essencialmente arbitrário, desde que a memória disponível o permita.

A velocidade de compilação é uma questão importante, mas não a principal, espera-se que programas pequenos sejam compilados dentro do intervalo de um segundo em máquinas mais potentes.

O caráter amistoso de um compilador em relação ao usuário se mostra principalmente na qualidade de seus relatórios de erros. No mínimo, o usuário deve receber uma mensagem de erro clara que inclua a causa percebida do erro, o nome do arquivo de entrada e a posição nesse arquivo.

A importância da velocidade e do tamanho do código gerado depende totalmente do propósito do compilador. Em geral, pode-se esperar que o usuário esteja mais interessado em alta velocidade que em tamanho pequeno (exceto o código para aplicações embarcadas utilizando  microcontroladores e etc).

No próximo artigo entrarei no assunto das gramáticas que é bem interessante e sem ela não existiria o formalismo da linguagem.

Qualquer dúvida entre em contato.


Final

11.4.2.13.26         Na representação abaixo, o “Programa A” é interoperável, intercomunicável e intercambiável com o “Sistema Operacional A”, por apresentarem a mesma “arquitetura” e as mesmas sequências binárias:


11.4.2.13.27         Os respectivos sistemas operacionais e programas da “Organização nº 01” e da “Organização nº 02” são interoperáveis, intercomunicáveis e intercambiáveis entre si, por apresentarem a mesma “arquitetura” e as mesmas sequências binárias, razão pela qual essas duas organizações hipotéticas não teriam nenhuma dificuldade para se unirem para criar a “Rede de Relacionamento Virtual nº 01”, com vistas à unificação da infra-estrutura tecnológica e de rede voltada para as “Experiências Eletrônicas” de “Clientes Digitais”, sem ter que criarem e manterem arquiteturas diferentes:


11.4.2.13.28         Os respectivos sistemas operacionais e programas da “Organização nº 03” e da “Organização nº 04NÃO SÃO INTEROPERÁVEIS, INTERCOMUNICÁVEIS e INTERCAMBIÁVEIS entre si, por apresentarem diferentes “arquiteturas” e diferentes sequências binárias, razão pela qual essas duas organizações hipotéticas:


11.4.2.13.29         Notemos na figura abaixo que se a se a “Organização nº 03 criar para o “Sistema Operacional C”, uma arquitetura adicional, que não existia anteriormente, que é a mesma da “Organização nº 04”, poderá, assim, apresentar a mesma “arquitetura” e as mesmas sequências binárias, razão pela qual essas duas organizações hipotéticas (“Organização nº 03” e “Organização nº 04” poderão se unir para criar a “Rede de Relacionamento Virtual nº 02”, com vistas à unificação da infra-estrutura tecnológica e de rede voltada para as “Experiências Eletrônicas” de “Clientes Digitais”, mas a “Organização nº 03” passa a ter que manter e adaptar duas arquiteturas diferentes, o que é inviável sob o ponto de vista prático, de custos e de riscos:


11.4.2.13.30         Por causa das diferenças de arquitetura, um programa pode funcionar em um sistema operacional, mas não funcionar em outro sistema operacional e essas diferenças de arquitetura são um problema, estrutural, sério, à ambição da humanidade para criar “Redes de Relacionamentos Virtuais” e “Ecossistemas de Relacionamentos VirtuaisINTEROPERÁVEIS, INTERCOMUNICÁVEIS e INTERCAMBIÁVEIS entre si, com vistas à unificação da infra-estrutura tecnológica e de rede voltada para as “Experiências Eletrônicas” de “Clientes Digitais”.

11.4.2.13.31         Contudo, pode-se pensar em alternativas de solução para esse problema, aparentemente, sem solução prática, economicamente e operacionalmente viável.

11.4.2.13.32         Para que as organizações não tenham que criar e manter diversas arquiteturas, diferentes, conforme item “a” a seguir, uma possível alternativa a ser avaliada do ponto de vista de ser ou não uma solução prática e viável, seria a criação de “COMPILADOR DE MÚLTIPLAS ARQUITETURAS DIFERENTES”, conforme item “b” abaixo:

a)        Arquiteturas diferentes:



b)        COMPILADOR DE MÚLTIPLAS ARQUITETURAS DIFERENTES”:


11.4.2.13.33         No COMPILADOR DE MÚLTIPLAS ARQUITETURAS DIFERENTES”, conforme tabela acima, a “Organização nº 01”, que só opera com o “Tipo de Arquitetura A”, se relaciona, em “Rede de Relacionamento Virtual nº 01”, com 07 (sete) outras organizações (“Organização nº 02”, “Organização nº 03”, “Organização nº 04”, “Organização nº 05”, “Organização nº 06”, “Organização nº 07” e “Organização nº 08”), sendo que cada uma dessas sete organizações possui um “Tipo de Arquitetura” e um “Código de Arquitetura” diferentes da “Organização nº 01”, mas a “Organização nº 01” se relaciona, eletronicamente, com as sete outras organizações, pois ao demandar uma transação à “Organização nº 02”, por exemplo, o “COMPILADOR DE MÚLTIPLAS ARQUITETURAS DIFERENTES” verifica, em campo específico, qual é o “Tipo de Arquitetura” e o “Código da Arquitetura” da “Organização nº 01”, “traduz” o “Tipo Arquitetura A” e o “Código Arquitetura 000004AAX”, da “Organização nº 01”, para o “Tipo Arquitetura B” e o “Código Arquitetura 0000005AAX”, da “Organização nº 02” e, dessa forma, duas organizações, diferentes, com arquiteturas diferentes, conseguem trocar informações por meio da mesma “Rede de Relacionamento Virtual nº 01”.

11.4.2.13.34         O esforço para criação do “COMPILADOR DE MÚLTIPLAS ARQUITETURAS DIFERENTES” é único e, uma vez criado, pode ser disponibilizado para todas as empresas utilizarem, no Brasil e no exterior, sendo que a “versão universal” teria duas partes, uma parte em código fechado, contemplando as principais arquiteturas utilizadas no mercado, e uma segunda parte em código aberto, a ser desenvolvida pelas empresas que não utilizariam as principais arquiteturas utilizadas no mercado, não contempladas na parte em código fechado ou que seria utilizada (segunda parte do “COMPILADOR DE MÚLTIPLAS ARQUITETURAS DIFERENTES”) como mecanismo de segurança, específico, para relacionamento entre partes restritas no mercado. Exemplo?

11.4.2.13.35         O “Banco Central A”, no “País A”, utiliza a “versão universal” do “COMPILADOR DE MÚLTIPLAS ARQUITETURAS DIFERENTES”, contendo a parte em código fechado, contemplando as principais arquiteturas utilizadas no mercado, para se relacionar com as instituições financeiras, internamente e externamente, por exemplo.

11.4.2.13.36         O “Banco Central B” do “COMPILADOR DE MÚLTIPLAS ARQUITETURAS DIFERENTES”, no “País B”, utiliza a “versão universal”, contendo a parte em código fechado, contemplando as principais arquiteturas utilizadas no mercado, para se relacionar com as instituições financeiras, internamente e externamente, por exemplo.

11.4.2.13.37         Contudo, o Bank for International Settlements-BIS (https://www.bis.org), deseja criar, na segunda parte do “COMPILADOR DE MÚLTIPLAS ARQUITETURAS DIFERENTES”, uma arquitetura, específica e proprietária, conhecida, apenas entre o Bank for International Settlements-BIS e o “Banco Central A” e o “Banco Central B”, para processar as trocas de informações de pagamentos internacionais e sensibilização de reservas bancárias entre o “País A” e o “País B”, por exemplo, como forma de ter mais segurança no tráfego dessas informações, criptografadas, transitando, pela Internet ou pela “Cloud Computing”, o que AUMENTA A SEGURANÇA DIGITAL, MEDIANTE COMPARTILHAMENTO, COLETIVO E COLABORATIVO, DOS MECANISMOS CONTRA FRAUDES ELETRÔNICAS, descritos no “Projeto de Segurança de Lógica Quântica - Módulo 06/33”, nas lâminas 139 a 246, do “Planejamento Estratégico Para Criação de Economia Digital no Brasil e no Mundo - Parte 01”, link http://www.rogerounielo.blogspot.com.br/2016/01/economia-digital-planejamento.html, bem como disponível no YouTube, link https://youtu.be/UeBjJZ7ttK0, a partir dos 11 minutos e 28 segundos, bem como, também, descrita, nos itens 15.1 a 15.6, anteriores, com a adoção de CERTIFICAÇÃO DIGITAL E DE ASSINATURA DIGITAL, NO PADRÃO ICP-BRASIL, REGULADO PELO ARTIGO 1º, DA MEDIDA PROVISÓRIA 2.200-2, DE 24/08/2001, OU EM PADRÃO DE CERTIFICAÇÃO DIGITAL E DE ASSINATURA DIGITAL INTERNACIONAL, A SER DESENVOLVIDO, FUNCIONANDO O COMPILADOR DE MÚLTIPLAS ARQUITETURAS DIFERENTES”, SEGUNDA PARTE, EM CÓDIGO ABERTO, conhecida, apenas, entre o Bank for International Settlements-BIS e o “Banco Central A” e o “Banco Central B”, para processar as trocas de informações de pagamentos internacionais e sensibilização de reservas bancárias entre o “País A” e o “País B”, por exemplo, E OS CERTIFICADOS DIGITAIS E AS ASSINATURAS DIGITAIS, NACIONAIS E INTERNACIONAIS, COMO MECANISMOS DE SEGURANÇA, ADICIONAIS, além da utilização dos 27 (vinte e sete) “Modos de Segurança”, de lógica quântica, citados anteriormente.

11.4.3           Como é possível a duplicação de cada um dos ELEMENTOS CONSTITUINTES DE PROCESSOS ELETRÔNICOS DIGITAIS (criação, instantânea e on-line, de várias cópias, da mesma “Peça de Programação”, e/ou criação, instantânea e on-line, de várias cópias, do mesmo “Programa”, e/ou criação, instantânea e on-line, de várias cópias, do mesmo “Sistema”, e/ou criação, instantânea e on-line, de várias cópias, da mesma “Rotina”, e/ou criação, instantânea e on-line, de várias cópias, da mesma “Sub-Rotina”, e/ou criação, instantânea e on-line, de várias cópias, do mesmo “Aplicativo”, e/ou criação, instantânea e on-line, de várias cópias, do mesmo “Canal”, e/ou criação, instantânea e on-line, de várias cópias, da mesma “Interface de Canal”, e/ou criação, instantânea e on-line, de várias cópias, da mesma “API-Application Programming Interface ou Interface de Programação de Aplicativos”, etc., e, também, CRIAÇÃO, INSTANTÂNEA e ON-LINE, de várias cópias, de cada um dos sistemas operacionais, primários e básicos, dos próprios computadores, conforme descrição contida nos itens 11 a 11.1.5.25, anteriores), e quais são as vantagens em adotar inteligência organizativa de tecnologia da informação, NOVA, para duplicar OS MESMOS ELEMENTOS CONSTITUINTES DE PROCESSOS ELETRÔNICOS DIGITAIS, utilizando métodos de customização massificada, detalhados nos itens 53 a 53.22, abaixo, para “Competir Digitalmente”, em setores econômicos digitais, e para “Competir Digitalmente”, em atividades econômicas digitais, na economia digital, da “Era Digital”, no Brasil e nos demais países do mundo?

11.4.4        Na “Arquitetura de TI Padrão”, idealizada para a “Era Industrial”, que traz em seu “DNA”, métodos de produção em massa, para mercados grandes, homogêneos e estáveis, por décadas, detalhados nos itens 52 a 52.22, abaixo, as mesmas funcionalidades, lógicas, estão incorporadas, simultaneamente, em cada um dos ELEMENTOS CONSTITUINTES DE PROCESSOS ELETRÔNICOS DIGITAIS, diferentes, que funcionam separadamente, de forma estanque, não se comunicando entre si, não sendo interoperáveis, entre si, e não sendo intercomunicáveis, entre si, como, por exemplo, em códigos de programas distintos, integrados, separadamente, de forma estanque, em sistemas distintos, para realizarem a mesma função (“Programa nº 01”, para calcular e cobrar “Tributo nº 01”, sobre operações financeiras, realizadas no “Sistema A”, e “Programa nº 02”, para calcular e cobrar “Tributo nº 01”, sobre operações financeiras, realizadas no “Sistema B”, por exemplo), duplicando os esforços de desenvolvimento, duplicando os esforços de testes, duplicando os esforços de implantação, duplicando os esforços de manutenção, e duplicando os esforços de alterações (implantação de modificações, no “Programa nº 01”, para modificar o cálculo da metodologia e da alíquota, para cobrar o “Tributo nº 01”, sobre operações financeiras, realizadas no “Sistema A”, e implantação de modificações, no “Programa nº 02”, para modificar o cálculo da metodologia e da alíquota, para cobrar o “Tributo nº 01”, sobre operações financeiras, realizadas no “Sistema B”, por exemplo), contexto que, também, se aplica para criação de produtos e serviços, digitais, com alocação de mais e mais analistas, de sistemas, na medida em que o tempo passar, para cuidar de tantos NOVOS sistemas legados, aplicativos, canais, interfaces de canais etc., que se multiplicam, EXPONENCIALMENTE, em setores econômicos digitais e em atividades econômicas digitais, na economia digital, fruto do surgimento de novos contextos de “Experiências Eletrônicas”, dos “Clientes Digitais”, no “Mundo Virtual”.

11.4.5                 Na “Arquitetura de Programação de TI Lego”, idealizada para setores econômicos digitais, e idealizada para atividades econômicas digitais, da economia digital (“Era do Conhecimento”, base da economia digital), as funcionalidades lógicas são incorporadas em “Peças Lego Virtuais de Programações Orientadas a Objeto”, utilizando métodos de customização massificada, detalhados nos itens 11.4.5.1.1 a 11.4.5.1.23, abaixo, métodos esses de customização massificada utilizados na criação do PROCESSAMENTO PARALELO POR DUPLICAÇÃO, INSTANTÂNEA, ON-LINE, DOS MESMOS ELEMENTOS CONSTITUINTES DE PROCESSOS ELETRÔNICOS DIGITAIS e, também, NA CRIAÇÃO, INSTANTÂNEA e ON-LINE, de várias cópias de cada um dos sistemas operacionais, básicos e primários, dos próprios computadores, conforme descrição, anterior, contida nos itens 11 a 11.1.5.25, Peças Lego Virtuais de Programações Orientadas a Objeto” essas obtidas por meio, ainda, da aplicação das novas “Metodologias da Nova Inteligência Organizativa da Programação Utilizadas Para Criação do “Sistema Operacional TOTAL” e do “Programa de Virtualização TOTAL”, cujo detalhamento pode ser encontrado nas lâminas 82 a 91 e 259 a 275, do “Planejamento Estratégico Para Criação de Economia Digital no Brasil e no Mundo - Parte 01”, link http://www.rogerounielo.blogspot.com.br/2016/01/economia-digital-planejamento.html, também, disponível no YouTube, link https://youtu.be/UeBjJZ7ttK0, a partir dos 06 minutos e 46 segundos e 22 minutos e 04 segundos, respectivamente, e nas lâminas 106 a 138 desse mesmo planejamento, a partir dos 08 minutos e 45 segundos,  transcritas (metodologias) no item 11.4.1, anterior.

11.4.5.1             As “Peças Lego Virtuais de Programações, Orientadas a Objeto nº 01”, originais, utilizadas para criar a “Programação”, as “Peças Lego Virtuais de Programações, Orientadas a Objeto nº 02”, originais, utilizadas para criar os “Programas”, as “Peças Lego Virtuais de Programações, Orientadas a Objeto nº 03”, originais, utilizadas para criar os “Sistemas”, as “Peças Lego Virtuais de Programações, Orientadas a Objeto nº 04”, originais, utilizadas para criar as “Rotinas”, as “Peças Lego Virtuais de Programações, Orientadas a Objeto nº 05”, originais, utilizadas para criar as “Sub-Rotinas”, as “Peças Lego Virtuais de Programações, Orientadas a Objeto nº 06”, originais, utilizadas para criar os “Canais”, as “Peças Lego Virtuais de Programações, Orientadas a Objeto nº 07”, originais, utilizadas para criar as “Interfaces de Canais”, as “Peças Lego Virtuais de Programações, Orientadas a Objeto nº 07”, originais, utilizadas para criar as “API-Application Programming Interface ou Interface de Programação de Aplicativos”, etc., por meio de criação de várias cópias, INSTANTÂNEAS, ON-LINE, de referidos ELEMENTOS CONSTITUINTES DE PROCESSOS ELETRÔNICOS DIGITAIS (“Peças de Lego Virtuais de Programações de Tecnologia da Informação”, por meio das quais se criam Peças de Programação”, por meio das quais se criam “Programas”, por meio das quais se criam “Sistemas”, por meio das quais se criam “Rotinas”, por meio das quais se criam “Sub-Rotinas”, por meio das quais se criam “Aplicativos”, por meio das quais se criam “Canais”, por meio das quais se criam “Interfaces de Canais”, por meio das quais se criam “API-Application Programming Interface ou Interface de Programação de Aplicativos”, e por meio das quais se criam quaisquer dos “ELEMENTOS CONSTITUINTES DE PROCESSOS ELETRÔNICOS DIGITAIS) são guardadas em “Biblioteca”.

11.4.6                 Uma vez que as “Peças Originais de Lego Virtuais de Programações, Orientadas a Objeto” estão prontas, acabadas e definidas, são guardadas, na “Biblioteca”, para, posteriormente, serem duplicadas ou replicadas, várias vezes, a partir da “Biblioteca”, para serem incorporadas em diferentes programas, para serem incorporadas em DIFERENTESSistemas”, para serem incorporadas em DIFERENTESCanais”, para serem incorporadas em DIFERENTESInterfaces de Canais”, para serem incorporadas em DIFERENTESRotinas”, para serem incorporadas em DIFERENTESSub-Rotinas”, para serem incorporadas em DIFERENTESCanais”, para serem incorporadas em DIFERENTESInterfaces de Canais”, para serem incorporadas em DIFERENTESElementos Constituintes de Processos Eletrônicos Digitais”, para serem incorporadas em DIFERENTESSistemas Operacionais, Primários e Básicos, dos Próprios Computadores”, para serem incorporadas em DIFERENTESOutras Peças de Lego Virtuais de Programações Orientadas a Objeto”, para serem incorporadas em DIFERENTESAPI-Application Programming Interface ou Interface de Programação de Aplicativos”, etc., preservando-se, sempre, intacta, as “Peças Originais de Lego Virtuais de Programações, Orientadas a Objeto”, guardadas na “Biblioteca”, para SEREM CRIADAS, INSTANTANEAMENTE, ON-LINE, NOVOS, DOS MESMOS ELEMENTOS CONSTITUINTES DE PROCESSOS ELETRÔNICOS DIGITAIS,  QUE DEMONSTRAREM TEREM SE TRANSFORMADO EM COMPONENTES DIGITAIS QUE LIMITAM A EXPANSÃO DA CAPACIDADE, MÁXIMA, DE PROCESSAMENTO DO COMPUTADOR, E QUE IMPEDEM QUE REFERIDA CAPACIDADE, MÁXIMA, DE PROCESSAMENTO, DO COMPUTADOR, SEJA AUMENTADA, para aumentar, PROVISORIAMENTE e TEMPORARIAMENTE, referida CAPACIDADE, MÁXIMA, DE PROCESSAMENTO, DO(S) COMPUTADOR(ES), por meio da criação, instantânea e on-line, dos Elementos Constituintes de Processos Eletrônicos Digitais, que limitam a EXPANSÃO DA CAPACIDADE, MÁXIMA, DE PROCESSAMENTO, DO(S) COMPUTADOR(ES), quando for necessário, em várias dimensões, INCLUSIVE,  de PROCESSOS ELETRÔNICOS DIGITAIS, PRIMÁRIOS E BÁSICOS, DO(S) COMPUTADOR(ES), que hoje não são possíveis de serem aumentados, por meio da criação, instantânea e on-line, para EXPANDIR A CAPACIDADE, MÁXIMA, DE PROCESSAMENTO, DO(S) COMPUTADOR(ES), por causa da inteligência organizativa, ultrapassada, utilizada na construção das estruturas, lógicas, de processamento do(s) computador(es), originalmente concebidas para atender a “Era Industrial”, com mercados grandes, homogêneos e estáveis, por décadas, construídas -- estruturas, lógicas, de processamento do(s) computador(es) --, com base nos métodos de produção em massa, detalhados nos itens 52 a 52.22, abaixo.

11.4.6.1             Várias Peças Lego Virtuais de Programações, Orientadas a Objeto, Constituídas, Simultaneamente, Por Vários Elementos Constituintes de Processos Eletrônicos Digitais, Orientados a Objeto”, denominados de “Objetos Virtuais”, criados, com base no detalhamento técnico, contido nos itens 18 a 18.13, abaixo, que, por sua vez são incorporados em “Caixas Virtuais”, constituídas por 07 (sete) “Brinquedos Virtuais”, com cada “Brinquedo Virtual” constituído por 07 (sete) “Objetos Virtuais”, que, por sua vez são incorporados em “PilHas de Caixas Virtuais”, constituídas por 07 (sete) “Caixas Virtuais”.



SÓ A FRATERNIDADE E UNIÃO ENTRE OS SERES HUMANOS, DO MUNDO, PODERÁ RESOLVER OS PROBLEMAS SOCIAIS, AMBIENTAIS, ECONÔMICOS, FINANCEIROS E DE RELACIONAMENTO, DO PLANETA TERRA. NÃO HÁ IDEOLOGIA SUPERIOR À FRATERNIDADE UNIVERSAL

“quando os bons não se apresentam ao campo de batalha a vitória da injustiça é justa.”.

“O poder que os homens possuem, no Planeta Terra, serve para nos ensinar que o maior PODER DO MUNDO é o PODER de dominar-se a si mesmo, que é um PODER MENOR, que te leva ao PODER MAIOR, QUE É NÃO TER PODER ALGUM, QUE É O MAIOR DE TODOS OS PODERES”.




"No vazio, na solidão e no silêncio da mente, a consciência pura, imóvel, sem movimento, integrada ao "Não-Ser", "Causa Sem Causa", por "Não Ser", junto com a "Causa Sem Causa", como a gota de água da chuva que cai pelo espaço e se integra, novamente, ao oceano, "capta instantaneamente", de forma absoluta, todas as infinitas possibilidades de "Ser" que o "Não-Ser" pode vir a assumir existencialmente, nas infinitas dimensões, ontologicamente falando, "ao mesmo tempo", na eternidade, factualizando suas infinitas possibilidades de consciência consciente, cópia, imperfeita, em processo de realização da perfeição do Pai Universal Único, da consciência inconsciente absoluta".


CONTINUA NA PARTE 06

Evite fracassos com a transformação digital da sua organização e do seu país para a economia digital

1.           ÍNDICE DO MANUAL ESTRATÉGICO, TÁTICO, TÉCNICO, TECNOLÓGICO, JURÍDICO DIGITAL, OPERACIONAL E INTRODUTÓRIO DO PROCESSAMENTO GEOMÉTRICO QUÂNTICO DIVULGADO EM 02/09/2016 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/08/destinatarios-organizacoes-publicas.html

2.           Nova Ordem Mundial - Projeto Base - Criação de Moeda Digital Única - Módulo 03/33 - Evite Fracassos Com a Transformação Digital - Manual Estratégico, Tático, Técnico, Tecnológico, Jurídico Digital, Operacional e Introdutório do Processamento Geométrico Quântico - PARTE 01 - Índice e item 1 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/02/evite-fracassos-com-transformacao.html

3.           PARTE 02 - Item 1.1 a Item 1.8.5.2.3 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/03/evite-fracassos-com-transformacao.html

4.           PARTE 03 - Item 1.9 a Item 5.4.3.1.3 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/03/evite-fracassos-com-transformacao_20.html

5.           PARTE 04 - Item 5.4.3.1.4 a Item 11.4.2.13 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/03/evite-fracassos-com-transformacao_26.html

6.           PARTE 05 - Item 11.4.2.13.1 a Item 11.4.6.1 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao.html

7.           PARTE 06 - Item 11.4.6.2  a Item 11.4.7.8 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_2.html  

8.           PARTE 07 - Item 11.4.7.9 a Item 11.4.7.11.12.6.21 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_17.html

9.           PARTE 08 - Item 11.4.7.11.12.6.22 a Item 11.4.7.11.12.6.54 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_63.html  

10.       PARTE 09 - Item 11.4.7.11.12.6.55 a Item 11.4.7.11.12.6.127.21 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_0.html

11.       PARTE 10 - Item 11.4.7.11.12.6.127.22 a Item 11.4.7.11.12.6.139 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_35.html

12.       PARTE 11 - Item 11.4.7.11.12.6.140 a Item 11.4.7.11.12.6.171 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_80.html

13.       PARTE 12 - Item 11.4.7.11.12.6.172 a Item 11.4.7.11.12.6.221 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criaca o_37.html

14.       PARTE 13 - Item 11.4.7.11.12.6.222 a Item 11.4.7.11.12.7.2 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_3.html

15.       PARTE 14 - Item 11.4.7.11.12.7.3 a Item 11.4.11.3 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_50.html

16.       PARTE 15 - Item 11.4.11.4 a Item 11.9.8 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_49.html

17.       PARTE 16 - Item 11.9.9 a Item 11.10.6 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_23.html

18.       PARTE 17 - Item 11.10.7 a Item 12.7.13 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_1.html

19.       PARTE 18 - Item 12.7.14 a Item 12.8 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_60.html

20.       PARTE 19 - Item 12.8.1 a Item 18.13.2 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_4.html

21.       PARTE 20 - Item 19 a Item 34.1.3 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_86.html

22.       PARTE 21 - Item 34.2 a Item 41.7.2.6 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_20.html

23.       PARTE 22 - Item 41.7.2.7 a Item 48.2.1.10 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_22.html

24.       PARTE 23 - Item 48.2.1.11 a Item 56 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_73.html


25.       PARTE 24 - Item 57 a Item 61 - Fonte - Link http://rogerounielo.blogspot.com.br/2016/11/nova-ordem-mundial-projeto-base-criacao_90.html

Brasília-DF, Brasil, 02/09/2016

Atenciosamente, 

Rogerounielo Rounielo de França
Advogado - OAB-SP 117.597
Especialista em Direito Público
Especialista em Marketing - FGV - Núcleo de Brasília


Participante do Fórum de Discussão “Segundas Filosóficas” - “http://segundasfilosoficas.org - “Somos capazes de sonhar com um mundo melhor. Seremos também capazes de projetá-lo e de efetivamente construí-lo?”

Nenhum comentário:

Postar um comentário