I intend to participate in Google's Summer of Code this year, so I'd
like to bounce another idea around to see what you guys think. (I posted
a similar message to cfe-dev just now.) Be warned: this will shock you.
It may even horrify you.
1. Implement a 16-bit x86 backend. (*Chris recoils in horror*) Yeah, I
know 16-bit x86 is dead, but I find it interesting for historical
purposes (and also because the Wine project wants a 16-bit compiler to
make 16-bit regression tests :). Besides, then we can have a 16-bit
assembler, and we won't need GAS anymore to build boot loaders and the like.
I intend to participate in Google's Summer of Code this year, so I'd
like to bounce another idea around to see what you guys think. (I posted
a similar message to cfe-dev just now.) Be warned: this will shock you.
It may even horrify you.
1. Implement a 16-bit x86 backend. (*Chris recoils in horror*) Yeah, I
/me recoils.
know 16-bit x86 is dead, but I find it interesting for historical
purposes (and also because the Wine project wants a 16-bit compiler to
make 16-bit regression tests :). Besides, then we can have a 16-bit
assembler, and we won't need GAS anymore to build boot loaders and the like.
I'd really rather not do this. There is a high maintenance cost to having backends in the tree (every codegen change requires updating all backends). Adding stuff that noone uses and can barely test is not goodness.
I intend to participate in Google's Summer of Code this year, so I'd
like to bounce another idea around to see what you guys think. (I posted
a similar message to cfe-dev just now.) Be warned: this will shock you.
It may even horrify you.
1. Implement a 16-bit x86 backend. (*Chris recoils in horror*) Yeah, I
/me recoils.
I knew you would
know 16-bit x86 is dead, but I find it interesting for historical
purposes (and also because the Wine project wants a 16-bit compiler to
make 16-bit regression tests :). Besides, then we can have a 16-bit
assembler, and we won't need GAS anymore to build boot loaders and the like.
I'd really rather not do this. There is a high maintenance cost to having backends in the tree (every codegen change requires updating all backends). Adding stuff that noone uses and can barely test is not goodness.
As you can tell, I figured this would be your response. So, I guess I'll
maintain it privately if I ever need it.
Or, perhaps, I could extend the existing x86 backend to support 16-bit.
It already supports 32-bit and 64-bit. But then again, I get the feeling
that you don't like that, either.
There is a high maintenance cost to having backends in the tree (every
codegen change requires updating all backends). Adding stuff that
noone uses and can barely test is not goodness.
So, proposing a backend for an unpopular architecture is not a good idea
for GSoC project in general?
We generally prefer for GSoC projects that are useful to a broad range of people or that opens llvm to a new community. A proposal that implements something that no one will use is highly unlikely to be accepted.
Is anyone interested in a SoC project to further develop Clang's support for detecting undefined behaviors in C/C++?
This is actually a collection of many smaller projects ranging from very easy (detecting divide by zero) to rather nasty (detecting references to out-of-scope automatic variables).
If someone does this, I'm happy to help mentor, provide test cases, etc.
If done well, this would be a relatively high-impact project. It would catch more errors than valgrind, be faster, and provide much better error messages.
Does the C backend serve as a backend of last resort, so to speak?
That is, can it be used to generate code for any platform for which
there is a C compiler (which presumably would include such 16 bit
chips as are still in use for embedded systems and not directly
supported by LLVM)?
mån 2010-03-22 klockan 17:23 -0700 skrev Chris Lattner:
We generally prefer for GSoC projects that are useful to a broad range
of people or that opens llvm to a new community.
My idea was to propose bringing LLVM to Inferno OS (the complement
project of Plan 9 from Bell Labs). This OS has a virtual machine (called
Dis) included in the kernel, which is the only option to write
user-level applications. Unfortunately only one language can be compiled
to its bytecode (Limbo). Inferno does not enjoy significant recognition
from general audience, nevertheless it is used in as an embedded OS and
a VM running on top of another OS (it is not intended to be a
yet-another-language-VM though).
Robust compiler infrastructure can attract more developers to Inferno.
Lack of support of popular languages is one of major problems on the way
of its adoption. It is a better platform to start exploring fundamental
ideas of Plan 9 than Plan 9 itself, because there are no hardware
compatibility problems by design, as the kernel has out-of-the-box
support for running as a user process on a different OS.
This work could start with implementing a backend emitting Dis bytecode.
For languages that employ pointer arithmetic some kind of sandbox should
be added. Later, support of JIT optimizer from LLVM could be added also.
Does all this count as opening LLVM to a new community?
Generally yes, but it has some inherent limitations (no exception support, poor debugging support) as well as some current problems (no support for "weird" integer sizes.
I am Qiuping Yi. I am interested in John’s SoC project idea, developing
Clang’s support for detecting undefined behaviors in C/C++, and hope John
to be my mentor.
I wish to implement detecting some undefined behaivors ranging from
easy (such as detecting divide by zero) to rather troublesome ones
(such as detecting references to out-of-scope automatic variables).
I know well about C/C++, and I major in program analysis and verification.
Now I am a grade-two master student of Institute of Software Chinese
Academy of Sciences, Beijing, China. I always pay close attention to many
compiler optimization technologies. Now I also attend another project
based on LLVM, in which I need to implement detecting whether the subscript
is out of the bounds of arrays.
I hope I can have a chance to make some contribution to LLVM and Clang.
I am Qiuping Yi. I am interested in John’s SoC project idea, developing
Clang’s support for detecting undefined behaviors in C/C++, and hope John
to be my mentor.
I wish to implement detecting some undefined behaivors ranging from
easy (such as detecting divide by zero) to rather troublesome ones
(such as detecting references to out-of-scope automatic variables).
I know well about C/C++, and I major in program analysis and verification.
Now I am a grade-two master student of Institute of Software Chinese
Academy of Sciences, Beijing, China. I always pay close attention to many
compiler optimization technologies. Now I also attend another project
based on LLVM, in which I need to implement detecting whether the subscript
is out of the bounds of arrays.
I hope I can have a chance to make some contribution to LLVM and Clang.
tis 2010-03-23 klockan 09:23 -0700 skrev Chris Lattner:
> Does all this count as opening LLVM to a new community?
Yes, particularly if the Plan 9 folks are interested in incorporating the result into their distribution.
There were some efforts to start a LLVM-based toolchain for Plan 9
during GSoC'09 (did not result in a project), and there are ongoing
discussions to try it this year. The same stands for Inferno toolchain
(it was never proposed before, though).
There are two administrative questions: which organization should mentor
these projects and in which source tree should the result be included?
There will be substantial amount of code that will be specific for Plan
9/Inferno, and probably it will not be welcome in LLVM tree. On the
other hand, a student may require mentoring by people from both
projects.
There are two administrative questions: which organization should mentor
these projects and in which source tree should the result be included?
There will be substantial amount of code that will be specific for Plan
9/Inferno, and probably it will not be welcome in LLVM tree. On the
other hand, a student may require mentoring by people from both
projects.
Having two mentors is not a problem at all. E.g. for llvm-qemu project
there were 2 mentors - one from qemu, another - from llvm.
There are two administrative questions: which organization should mentor
these projects and in which source tree should the result be included?
There will be substantial amount of code that will be specific for Plan
9/Inferno, and probably it will not be welcome in LLVM tree. On the
other hand, a student may require mentoring by people from both
projects.
Having two mentors is not a problem at all. E.g. for llvm-qemu project
there were 2 mentors - one from qemu, another - from llvm.
I believe projects this year require one primary mentor and a backup mentor (in case the primary mentor is unavailable).
I know pc-lint is working fine on detecting some nasty coding fault.
But is it illegal implement it in clang? And also there is so much
other tools for code analyze:)
I have discussed my proposal with people from Plan 9/Inferno
communities, and they have shown interest. There is substantial concern
about possibilities to implement pointer arithmetic in a safe VM. Right
now LLVM backends for Java and .NET VMs have shown some progress in this
direction. I have come up with a draft of proposal and I'd like to get
some feedback on it.
