[cfe-dev] Porting Clang to a new architecture

[Saleem Abdulrasool via cfe-dev]

On Monday, October 26, 2015, Ariel Arelovich <aarelovich at gmail.com> wrote:

> Great.
>

BTW, cfe-dev is the right mailing list for this conversation, not
cfe-commits.


> So this is what I wanted to know. I think understand what you are saying.
> You are saying that most of the work that I would need to do from the AST
> (I'm assuming that this stands from Abstract Syntax Tree) is allready being
> done by LLVM and I should look to modify for a my new arquitecture. Right?
>

The AST to IR conversion is the job of the frontend, and is already done by
clang.  You would need to add a new architecture backend to LLVM.  If you
have a different ABI, that will need to go into clang (depending on the
differences).


> If I take the AST and process it myself to generate the opcodes, I'm
> essentially writing LLVM just less efficient (no optimizations) and
> specific for the new architecure, right?
>

If you do that, you are going to rewrite part of clang.  There are a lot of
corner cases when it comes to handling ABI, and those issues are hard to
diagnose and time consuming to fix.

If you intend to write the backend outside of LLVM, it would be easier to
write something to go from LLVM IR to your custom representation.  As you
pointed out already, doing so means you lose out on all the optimizations
and it would be specific to your target architecture.


> On Mon, Oct 26, 2015 at 12:32 PM, Saleem Abdulrasool <
> compnerd at compnerd.org
> <javascript:_e(%7B%7D,'cvml','compnerd at compnerd.org');>> wrote:
>
>> On Monday, October 26, 2015, Ariel Arelovich via cfe-commits <
>> cfe-commits at lists.llvm.org
>> <javascript:_e(%7B%7D,'cvml','cfe-commits at lists.llvm.org');>> wrote:
>>
>>> Hi:
>>>
>>> Where I'm working I've been asked to look into developing a C (by this I
>>> mean C89 C standard) compiler a new processor architecture being created
>>> inhouse.
>>>
>>> On looking at the options and brushing up on compiler theory, I came up
>>> with Flex/Bison, Writing the compiler from scratch or use Clang. I liked
>>> this option better because parsing and and analyzing c code to genereate
>>> somthing intermediate, and do this from scratch, seemed like reinventing
>>> the wheel (an incredibly complex wheel, at that).
>>>
>>> I've figured that if Clang, works with the standard compiler flow (that
>>> I've seen everywhere), it takes a C program and transforms it until it gets
>>> a intermediate language (which is machine independant). The Dragon Book,
>>> even calls this the output of the compiler Front End. From what I've read
>>> from the documentation This is what Clang is: a compiler front end. LLVM
>>> does optimization and translation to opcodes of known architectures. Is
>>> this correct? Or am I getting this wrong?
>>>
>>
>> Correct.  clang is just the front end for C-like languages.  It will
>> parse and analyze the code (generating the AST).  The IR it generates is
>> the LLVM IR.
>>
>> So, my question is: Would it be possible to use Clang in such a way that
>>> it takes a C program and generates an intermediate language so that I can
>>> work directly on that language to generate opcodes based on the
>>> architecture that we are currently developing?
>>>
>>
>> Yes.  This is how clang already works.  It sounds like you should be
>> looking at LLVM, not clang since you are trying to support a new
>> architecture, not a language feature.
>>
>>
>>>
>>> Thank you, for any answers.
>>>
>>> PD: I know my question might be very hard to answer as it is not very
>>> specific. All I'm asking for, here, is a simple: "It could be done, start
>>> reading about this and that" or "It will be next to impossible, just try
>>> something else" (with a little explanation as to why, if that were
>>> possible, please).
>>>
>>
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>>
>
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151026/cfd033a1/attachment.html>