>Eu não curto muito conversas públicas.
> Se a conversa chegar a uma boa conclusão, um de nós faz um resumo
e publica.
> Por enquanto, eu estou só me divertindo.
>(Aceite isso como um elogio.)
Ok então.
Estou publicando este resumo agora!
---
>Sobre o Análise Semântica:
> É aquela fase do processo de compilação onde nos certificamos que
não estamos misturando alhos com bugalhos. (ou tentando somar string
com inteiro)
>Ou seja, tem a ver com verificação de tipos, é o ponto onde temos
que devemos percorrer a árvore sintática verificando os ramos para ser
se são compatíveis >entre si. Não é mesmo?
> Como está o projeto neste sentido?
Sim.
Já comecei, falta algum tempo para terminar.
> 2012/7/11 Anderson <
anderso...@gmail.com>
> Então maninho...
> Vamos chegar no analisador semântico. Vamos com calma com
o andor ;-)
> Mas antes eu preciso me familiarizar com o 'mind-frame'
do projeto. E por enquanto, eu gostaria de focar em um ponto que me
deixou feliz na sua >proposta:
> Permitir que programadores medianos consigam
entender, documentar, corrigir, otimizar e evoluir o frontend do
compilador.
> Como eu sou um programador mediano :| , minha proposta de
fazer um parser XML (ou mesmo JSON) juntamente com o projeto pascal, é
justamente >para demonstrar de que forma um parser XML e um parser
Pascal se relacionam. (princípio DRY)
> Isso pode parecer uma complicação aparentemente
desnecessária para o objetivo central do projeto que é um compilador
pascal. Mas, pense em como >um bom parser XML é uma ferramenta
importante em qualquer fase do desenvolvimento do compilador, para
comunicação e armazenamento. (Qualquer coisa em f>orma de árvore pode
ser facilmente representada como um XML para posterior análise.)
> Se a sua idéia é corrigir algumas redundâncias atualmente
encontradas nos sistemas do delphi e do fpc, esta é uma delas. Não há
porque termos duas >bases de códigos para realizar a mesma coisa.
> Imagine o seguinte modelo de classes:
> TParser = class
> TDataParser = class(TParser)
> TXMLParser = class( TDataParser)
> TJSONParser = class(TXMLParser)
> TPascalParser = class(TDataParser)
>Tudo o que for comum entre os parser devem estar nas
superclasses. Creio que isso além de ser uma boa prática OO, é uma
excelente instrumento de >aprendizado. Note que um Parser XML é um
JSON são semânticamente identicos apesar da sintaxe radicalmente
direfentes. Entende onde quero chegar?
O parser do LLVM-Pascal já está pronto, funcionando e testado com toda
a gramática do Object Pascal, é simples, fácil de entender,
customizável para outras linguagens de programação, tem alta
performance.
E está muito bem documentado no meu TCC. Veja pasta \Doc.
Portanto não pretendo mexer nele.
Estou caminhando para frente...
Próximo passo avançar analisador semântico, que já foi iniciado.
A parte final do gerador de código ToolChain já está em andamento pelo
Alekesey Naumov.
> Mas o meu interesse maior é pelo paralelismo, eu gostaria
de juntar o que eu venho pesquisando (sistema de actors). Estou aqui
fazendo um rascunho >(one mile high) da ideia para um compilador
paralelo e logo te passo.
Beleza.
> Gostaria que o nosso compilador :-) usasse todos os núcleos do meu computador e que mais de uma unit seja compilada de cada vez. :D
Acho isso bem importante.
Algo já para fazer é criar uma thread para o scanner (I/O bound),
outra para o parser sintático e semântico (CPU bound),
outra para o LLVM (misto CPU e I/O bound) e
outra para o link editor (I/O bound).
Essa separação já trará ganhos muito altos em hardwares multicore.
Só nisso já tem 4 threads, fora as do sistema operacional,
e sem se preocupar em compilar as units simultaneamente
-Wanderlan-