• Locked Locked
  • Replies 7 replies
  • Subscribers 119 subscribers
  • Views 3775 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

3x ARM

Marc Rainer Kranz
Note: This was originally posted on 3rd March 2013 at http://forums.arm.com

I am aware, i have few robust reasons against it: an ARM assembler, outputting ARM code
from a bare assembly language source and the whole... running on ARM.

it is fascinating me though :rolleyes:
What is your opinion, and why pros or contras ?

Thank You in advance,
Marc

p.s. should be this one a topic poll ?
  • Note: This was originally posted on 5th March 2013 at http://forums.arm.com


    Well... you can already do this.  The GNU tool chain can be built to run on ARM, and to output ARM.  But you would need an ARM system running Linux.

    hallo ttfn,
    thanks for answering. supposing an ARM system running Linux being enough mature to run such a "huge" toolchain,
    well, the best option i see, relating to tools like Keil armasm.exe, consists in a binary translation of it.
    also the question is now:
    how much is this a suggestable way,  considering i would like to avoid to rewrite the wheel
    one more time again for ARM too.
  • Note: This was originally posted on 5th March 2013 at http://forums.arm.com

    ...building a compiler based around binary translation of someone else's commercial product is probably against the terms of the license agreement =)

    of course yes, if someone else's license doesent allow it.

    ...what's wrong with GCC or LLVM, both of which can be compiled for ARM. LLVM in particular is pretty modular and you can remove optimization passes to make it smaller if needed.

    GCC looks like "huge" while on the other side a solution from LLVM, whenever modular, should output actually only opcodes (machine code),
    granted a system having stable libc-like functions. anyway, this solution may be advantageous, and i thought already about it using ANTLR.
  • Note: This was originally posted on 6th March 2013 at http://forums.arm.com


    *EDIT* One thing you can do to cut down work is write the compiler yourself, but emit assembler and then rely on existing tools to do the backend code generation. My toy compiler did this, using GCC's assembler to generate the ELF binaries.

    hallo Iso, sorry for delay. useful post.

    if you are not addressing a new language, this is indeed what GCC compiler already do,
    when developers have some reasons to profile/tune the code, because they do not trust
    what the compiler generates; also letting it emitting assembly code, hardworking it,
    then giving it finally to an assembler.

    in the case of a new language, the solution may be worth only after
    solving the problem of syncing line debugging informations.
    if your "toy compiler" does it well, i state it now a-priori,
    it should be not that "toy" afterall.

    but it is generally good to know that someone out there has raised some
    little doubt about those toolchains -being huge i mean.
    and i find somewhat bizarre the existence of embedded "jazelle"
    when on a development system like Linux-on-ARM the ELF format
    holds its abstraction and in the same moment only ARM instructions
    are being allowed to be executed in it

    consider please i may be wrong, because i am very new to ARM :)
    Regards,
  • Arm Employee Badge
    Note: This was originally posted on 5th March 2013 at http://forums.arm.com

    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]> well, the best option i see, relating to tools like Keil armasm.exe, consists in a binary translation of it. h[/size][/font][/color][color=#222222][font=Arial, Helvetica, sans-serif][size=2]ow much is this a suggestable way, considering i would like to avoid to rewrite the wheel[/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]
    [/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]Depending on what you are doing with it, I suspect building a compiler based around binary translation of someone else's commercial product is probably against the terms of the license agreement =)[/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]
    [/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]In terms of not reinventing the wheel, what's wrong with GCC or LLVM, both of which can be compiled for ARM. LLVM in particular is pretty modular and you can remove optimization passes to make it smaller if needed.[/size][/font][/color]
  • Arm Employee Badge
    Note: This was originally posted on 5th March 2013 at http://forums.arm.com

    ANTLR provides the front-end parser for the grammar of choice, but you're still writing the midend of the compiler from scratch. That's "really hard / really time consuming" - LLVM and GCC have years of development and hundreds of active developers.

    TBH it depends what you are really trying to achieve with the project.

    As a bit of fun side project - sure write your own, I have and I'm sure so have many others. However go in to it with your eyes open. Pros - it's very fun to work on, and very rewarding when it works. Cons - you are going to have a hard time getting your code generation quality/performance up to the same level as "commercial tools" or large scale open source projects. If you want a toy compiler for a limited set of use cases, go for it, but don't expect to beat existing compilers without a lot of work =)

    If you want to contribute to a commercial grade compiler, I'd suggest that writing your own from scratch is a hard proposition, and therefore I'd recommend the LLVM or GCC route. Pros - a lot of the boring framework generation is already done, and you don't have to be expert on everything. Linkers, libraries, and debugger support tools already exist. Cons - you don't have control over everything. Big pro - you are more likely to get things "into the field".

    Yes both GCC and LLVM compilers are "huge", and on top of that you have the linkers, loaders, binutils, and libraries. Developing a compiler infrastructure is expensive. Huge is good (albeit probably a bit scary with a learning curve) - it means someone else has invented most of the wheel for you =)

    *EDIT* One thing you can do to cut down work is write the compiler yourself, but emit assembler and then rely on existing tools to do the backend code generation. My toy compiler did this, using GCC's assembler to generate the ELF binaries.

    HTH,
    Iso
  • Arm Employee Badge
    Note: This was originally posted on 7th March 2013 at http://forums.arm.com

    > if you are not addressing a new language

    Even for new languages GCC and LLVM are an interesting approach because it is easy to remove the language-specific part (front-end) but re-use existing mid-end and back-end code generation. To a degree this makes life easier as it lets the language author focus on the efficiency of the language, without being distracted by the compiler, as the two are really separate problems.

    > [color=#222222][font=arial, helvetica, sans-serif]line debugging informations. [/font][/color]if your "toy compiler" does it well, i state it now a-priori, it should be not that "toy" afterall


    To my mind "toy" for compilers simply means less efficient than GCC, including libraries and debug support. If a new compiler in the wild can't complete with existing tools no commercial project is going to go near it. Therefore it is a project which is for fun - a.k.a a toy - toys are for fun too =)  Toy projects can be quite large, and often fairly well tested, but compilers face a serious hurdle to get out of the "just for fun" part.

    > but it is generally good to know that someone out there has raised some little doubt about those toolchains being huge

    GCC has a nicer internal architecture with 4.x, but personally I prefer LLVM to hack around with. It's a bit cleaner, and more modular. It is very easy to compile in or omit optimization passes, for example.

    > and i find somewhat bizarre the existence of embedded "jazelle" when on a development system like Linux-on-ARM the ELF format

    The Jazelle instructions are really designed for direct execution of (most) Java byte codes in hardware, and Thumb2 EE is designed for JIT targets such as Javascript. Neither are really static compiler target designed for offline tools like a traditional C compiler.
    [color=#222222][font=arial, helvetica, sans-serif][size=2]
    [/size][/font][/color]
    [color=#222222][font=arial, helvetica, sans-serif][size=2]> consider please i may be wrong, because i am very new to ARM[/size][/font][/color]
    [color=#222222][font=arial, helvetica, sans-serif][size=2]
    [/size][/font][/color]
    It's a good discussion - many people write compilers as projects =)
  • Arm Employee Badge
    Note: This was originally posted on 4th March 2013 at http://forums.arm.com

    Well... you can already do this.  The GNU tool chain can be built to run on ARM, and to output ARM.  But you would need an ARM system running Linux.