1 |
The Design of Intermediate Languages in Optimizing CompilersMaurer, Luke 31 October 2018 (has links)
Every compiler passes code through several stages, each a sort of mini-
compiler of its own. Thus each stage may deal with the code in a different
representation, which may have little to do with the source or target language.
We can describe these in-memory representations as languages in their own right,
which we call intermediate languages.
Each intermediate language is designed to accomodate the stage of
compilation that handles it. Those toward the end of the compilation pipeline,
for instance, tend to have features expressing low-level details of computation.
A subtler case is that of the optimization stage, whose role is to transform the
program so that it runs faster, uses less memory, and so forth. The optimizer faces
tradeoffs: The language should provide enough information to guide optimization
algorithms, but all of this information must be kept up to date as the program is
transformed. Also, establishing invariants in the language can be helpful both in
implementing algorithms and in debugging the implementation, but each invariant
may complicate desirable transformations or rule them out altogether. Finally, a
ivlanguage where the invariants are obviously correct may have a form too awkward
or otherwise unsuited to the compiler’s needs.
Given the properties and invariants that we would like the language to
provide, we can approach the design task in a way that gives these features without
necessarily sacrificing implementability. Namely, begin with a formal language that
makes the desired properties obvious, then translate it to one more suitable for
implementation. We can even translate theorems about valid transformations in the
formal language to derive correct algorithms in the implementation language.
This dissertation explores the connections between different intermediate
languages and how they can be interderived, then demonstrates how translation
lead to an improvement to the Glasgow Haskell Compiler opimization engine.
This dissertation includes previously published coauthored material.
|
2 |
Compilando Haskell para .NET via F#Kely de Melo Oliveira, Guilherme 31 January 2010 (has links)
Made available in DSpace on 2014-06-12T15:57:39Z (GMT). No. of bitstreams: 2
arquivo3216_1.pdf: 6659432 bytes, checksum: 29ec979f8895b39460684d09a38f9764 (MD5)
license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5)
Previous issue date: 2010 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / Diferentes linguagens de programação disponibilizam diferentes formas de se implementar
uma funcionalidade. Por exemplo, acessar um banco de dados usando C++ ou Python
podem ser duas tarefas completamente diferentes. Por outro lado, com o surgimento
da Plataforma .NET o acesso a dados com C++ .NET ou IronPython, por exemplo, se
tornaram atividades muito parecidas tendo apenas algumas diferenças sintáticas.
A Plataforma .NET é distribuída com um conjunto padrão de compiladores para
diferentes linguagens como C#, Visual Basic .NET, JScript e J#, todas são orientadas
a objetos. Com isso podemos notar uma maior atenção comercial dada ao paradigma
de orientação a objetos. No entanto, esse dado não significa que devamos concluir que
outros paradigmas não possam ser suportados, pelo contrário e a criação da linguagem
F# é um exemplo de que a Plataforma .NET pode dar suporte a diversos paradigmas.
Haskell é uma linguagem puramente funcional, não-estrita e fortemente tipada. E por
ser uma linguagem de alto poder de expressão e não permitir efeitos colaterais durante
sua execução, um programa escrito em Haskell se torna mais fácil de testar, otimizar e
paralelizar. No entanto há um grande vazio quando tocamos na questão de ferramentas e
APIs para Haskell.
Devido ao fato de desenvolvedores usarem uma grande gama de ferramentas e tecnologias,
cada qual com diferentes funcionalidades e tipos, tem sido historicamente
difícil garantir a interoperabilidade entre as linguagens. No entanto, os compiladores e
ferramentas que tem como alvo máquinas virtuais como a Plataforma .NET tiram proveito
do suporte a interoperabilidade entre linguagens inerente a esses tipos de sistemas.
O presente trabalho propõe um novo esquema de compilação de Haskell para a
Plataforma .NET utilizando F# como linguagem intermediária. Tal abordagem nos livra
dos inúmeros problemas que a geração de código diretamente para MSIL pode trazer,
possibilitando irmos um pouco mais além na questão da interoperabilidade
|
3 |
Experience with Acore: Implementing GHC with ActorsPalmucci, Jeff, Waldsburger, Carl, Duis, David, Krause, Paul 01 August 1990 (has links)
This paper presents a concurrent interpreter for a general-purpose concurrent logic programming language, Guarded Horn Clauses (GHC). Unlike typical implementations of GHC in logic programming languages, the interpreter is implemented in the Actor language Acore. The primary motivation for this work was to probe the strengths and weaknesses of Acore as a platform for developing sophisticated programs. The GHC interpreter provided a rich testbed for exploring Actor programming methodology. The interpreter is a pedagogical investigation of the mapping of GHC constructs onto the Actor model. Since we opted for simplicity over optimization, the interpreter is somewhat inefficient.
|
Page generated in 0.3535 seconds