• Locked Locked
  • Replies 7 replies
  • Subscribers 119 subscribers
  • Views 3778 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 ?
Parents
  • 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,
Reply
  • 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,
Children
No data