some pointer to understanding GCC source code - multicore

I'm student working on optimizing GCC for multi-core processor. I tried going through the source code, it is difficult to follow through it since I need to add some code to the back end. Can anyone suggest some good resource which explains the code flow through the different phases.
Also suggest some development environment for debugging GCC mainly to step through the code. Is it possible on windows?

As a starting point see Links and Selected Readings on GCC site. Of particular interest to you, I think, are:
GNU C Compiler Internals
Compilation of Functional Programming Languages using GCC -- Tail Calls by Andreas Bauer
Porting GCC for Dunces by Hans-Peter Nilsson
If you want to develop on Windows you probably need to start from MinGW (Minimalist GNU for Windows) Compiler Suite sources (it includes GNU GDB debugger), which is a port of GCC to Windows.
For a comfortable development environment I cannot help much because I don't develop in C++. But I suppose a good IDE for C/C++ is what you need: have a look at this comparison, there are plenty free/open source IDEs for Windows.
Update: I think ICI can also be of interest to you:
The Interactive Compilation Interface
(or 'ICI' for short) is a plugin
system with a high-level
compiler-independent and low-level
compiler-dependent API to transform
current compilers into collaborative
open modular interactive toolsets. The
ICI framework acts as a "middleware"
interface between the compiler and the
user-definable plugins. It opens up
and reuses the production-quality
compiler infrastructure to enable
program analysis and instrumentation,
fine-grain program optimizations,
simple prototyping of new development
and research ideas while avoiding
building new compilation tools from
scratch. For example, it is used in
MILEPOST GCC to automate compiler and
architecture design and program
optimizations based on statistical
analysis and machine learning. It
should enable universal self-tuning
compilers adaptable to heterogeneous,
reconfigurable, multi-core
architectures ranging from
supercomputers to embedded systems.
.. as the rest of projects under the Collective TUNING umbrella.
Note: Writing "compilers are one of the most complex programs there are", as BlueRaja wrote in comments, is an overstatement: there are very simple compilers and very complex compilers. But in compiler theory (once you have studied it) there is nothing esoteric. GCC is a complex program to understand as whatever BIG, poorly documented program out there1. So rizwanhudda don't be discouraged: start studying the documentation available and then ask GCC developers (on GCC irc channel, as suggested by nvl or GCC developers mailing list) to explain what is poorly (or not at all) documented.
In fact program comprehension is an active field of research.

I would suggest you to use the GCC irc channel, it is meant for discussion of development of GCC.

Related

Convert scala to native binary

What is the best way to convert scala (or bytecode) to native binary in order to increase performance
At this moment I see two solutions to convert jvm bytecode to sort of self-contained native binary:
Avian - lightweight embeddable JVM with AOT features
Excelsior JET - Commercial Java native compiler
Both should be compatible with Scala.
There are no direct native compilers for scala as I know. There some projects like Scala LLVM, but they are more about research and proof of concepts than ready to use tools
Although not a fully capable tool yet, the scala-native project is starting to become usable, though it's still at an early stage, it's under active development and is becoming more capable by the month. It's based on LLVM and clang, and will compile your scala sources to binaries, if the libraries you depend on are among those implemented at this early stage. (it's not yet working in Windows or cygwin, although it does work in the WSL environment).
Update: Windows support has been improving recently (fall 2021).
Whether performance is increased or not is a separate question, although most programs are likely to start up much more quickly.
Here's a link to the User's Guide
To create your own project: Minimal sbt project
The biggest limitations are that only a subset of java and scala standard libraries have been implemented so far, so you'll need to limit yourself to what's currently available, and not every project will only be feasible if you restrict yourself to 100% scala. Also, the documentation is a work in progress.
As a test, I created a command line tool for processing text files, and I was able to get it to work finally, although I did spend a bit of time figuring out how to accomplish various things, and mostly how to live with the available libraries. If necessary, you can also link to C/C++ libraries although I didn't need to for my small project.
Footnote as of June 2019: I'm having good luck with graalvm native-image. Here's the link:
https://www.graalvm.org/docs/reference-manual/aot-compilation/

Is there a cross-platform framework for C?

I am curious to know if there is any kind of programming library/framework for the C language for cross-platform programming of course. I mean there are already frameworks like Wxwidgets, Boost, Qt, U++ and etc for C++ available but I have not yet found any for C .
Updated Info:
We are trying to build an underlying Framework/library to be used in our project. We are going to eliminate the dotnet and instead provide a counterpart for those libraries which is fast and less demanding.
We will be working on a server/client based project, and thus the underlying services must be fast and also portable. GUI is not our priority now, but libraries providing threading capabilities is of importance to us.
And for the ANSI part, I think we are fine with that at the moment unless something changes that in the future.
if you write plain ANSI C, it should work on every POSIX system.
The most successful example of cross platform C library is standard C library itself (IMHO).
If you're looking for GUI toolkit GTK is the answer,
if you're looking for terminal UI, ncurses is pretty portable.
If you're looking for general use libraries, as long as they're written in ANSI C, should work almost everywhere, as long as it doesn't use system level APIs.
Can you just tell us, what kind of library/framework you are looking for ?
GTK+ is long established and actively maintained cross-platform C-only (or primarily) toolkit. You'll find not only on-line documentation but also books written about it. It is the framework backing up the GNOME project.
GTK+ is meant to build applications with UI, first of all. However, even if you don't need UI you'll find that some GTK+ components, namely GLib, provide general multiplatform support comparable with Qt. Actually, I needed a framework without UI at first and chose GLib over APR because I was able to find documentation and tutorials easier.
GTK+ was initially developed on UN*X an X-Windows which remains the platform where you can get it running the most easily. I wouldn't say that it is more difficult on Windows; it is just that you have more compiling environment options. I started with prepared GTK+ packages and MinGW but ended up integrating GTK+ with MSVC.
GTK+ exists for a long time and some people may find it old-school. On the other hand, it shows that it has proven to be stable and useful. There are also bindings for C++ and C#.
As with every big framework, the more you need from it the longer you will have to learn. But the other way round it works too; the more you learn the more you'll be able to do with it. Consistent coding style helps getting used to it.
--- Ferda

iPhone GCC / LLVM GCC or LLVM?

Im asking the experts here...
Does anybody have made some performance test about which compiler is the best for iPhone apps?
Since we have the choice between:
GCC 4.2
LLVM GCC 4.2
LLVM compiler 1.5
Im wondering which of the 3 offers the best performance...
I've done some quick test myself but haven't found much difference?
Which compiler are you using?
If you watch the WWDC 2010 session video 300, the Developer Tools State of the Union, you will see that Apple reports significant performance increases for applications built using the LLVM compiler over GCC (up to 60% faster in certain cases). There are additional improvements that can be made by using the Clang parser with the LLVM compiler. Watch Session 312 - "What's New in the LLVM Compiler" for more on this, as well as the sessions on LLVM from WWDC 2009, if you have them.
I saw a 20% speedup going from GCC to LLVM 1.5 in an informal benchmark within one of my applications, but it wasn't a rigorous test, so consider that only anecdotal evidence.
My recommendation is to use Clang + LLVM (LLVM Compiler 1.5) if you can for faster build times, more performant applications, and much better compiler errors. If you use C++ code or something else that the Clang parser cannot handle right now, use LLVM GCC to still get the performance benefits in your compiled application. Go to GCC only if that fails for some reason. It's a simple switch to hit in your build settings to gain even a small amount of extra performance for free in your end application.
LLVM Compiler 2.0, coming with Xcode 4, has full support for C++ and promises additional optimizations for compiled applications, along with more compile-time speedups. Xcode 4 even uses Clang as the syntax highlighting / code correction engine in the IDE. It's clear the direction that Apple is heading with their compilers.
I do not know about performance for the iPhone, but in other benchmarks, Clang generally compiles faster but produces slower code than GCC. Clang also has better error messages than GCC. Thus, it might be best to use Clang in development, and switch to GCC for final production builds. If you choose such an approach, make sure you have a good QA cycle, or a build system that will also build and test the GCC build, so you don't get any nasty compiler related surprises at the end.
C++ support in Clang is a bit behind that of GCC (and more C++ code has been tested and tweaked for GCC's quirks than Clang's), so if you need to use a lot of C++, GCC might be a better option.
Really, you will need to choose the best compiler for your needs. Benchmarks, and other people's results, can give you an indication of what to consider, but every program is different, so the best approach would be to benchmark your own program on the different compilers, and see which works best for you.
LLVM GCC 4.2 is what I use.
Clang does not handle C++ well enough, and it's very much a work in progress. It's a very promising toolkit, but it's just not stable enough for production at this time (in my experience).
Apple's definitely investing in Clang as their future compiler, but it is not a trivial project. Unfortunately, that puts many of us in a strange place, using one relatively old compiler and/or one very very new one (guess how many years it will before I can begin using features of c++0x in my codebases).
I've used the GCC frontend with LLVM backend with my codebases since it was available (at least, during testing). It's been publicly available for years, and is fairly stable. I've found the LLVM pass does produce smaller, faster executables in comparison to GCC alone (although I do more works targeting OS X than iOS). Frankly, I can't compile enough code with Clang alone to recommend it (plus, I have a lot of C++).
I've found the GCC+LLVM combo reliable. If reliability is your primary concern: begin with GCC, regularly test +LLVM in development, and regularly compile and test with Clang at each Clang release until you're satisfied with it. GCC+LLVM will usually be usable for today's production builds.
If speed is your concern, begin with GCC+LLVM, and test with Clang regularly (if that is an option for you -- it is not for me - too much c++).
Regarding Clang's parsing/lexing/generation: Clang aims to extremely standards compliant. They're doing well, but there are many features which are new or non-existent, which is why I suggest you be cautious, especially with C++.
I believe Apple's made their preferred compiler of the future obvious so... don't wait too long to test with Clang.
I 'd like to introduce you this amazing article Compiler Options in Xcode - GCC or LLVM?
You won't wanna miss a single word, especially the section Which to choose ?
With clang 1.5's C++ frontend is not the best, and I generally recommend against using it if you have to deal with any C++ code (this includes Objective-C++ code). In addition, I have experienced some weak linking problems when using clang, so to me, it's not ready for production if you have to deal with either of the above two cases.
That said, I have not noticed any real impact on performance between the two, though clang's errors and warnings are MUCH more useful than gcc's.
Food for thought.

Why isn't there a good scheme/lisp on llvm?

There is Gambit Scheme, MIT Scheme, PLT Scheme, Chicken Scheme, Bigloo, Larceny, ...; then there are all the lisps.
Yet, there's not (to my knowledge) a single popular scheme/lisp on LLVM, even though LLVM provides lots of nice things like:
easier to generate code than x86
easy to make C FFI calls
...
So why is it that there isn't a good scheme/lisp on LLVM?
LLVM provides a lot, but it's still only a small part of the runtime a functional language needs. And C FFI calls are uncomplicated because LLVM leaves memory management to be handled by someone else. Interacting the Garbage Collector is what makes FFI calls difficult in languages such as Scheme.
You might be interested in HLVM, but it's still more than experimental at this point.
For CL: Clasp is a Common Lisp implementation on LLVM, and mocl implements a subset of Common Lisp on LLVM.
For Scheme: there's a self-hosting Scheme->LLVM demo and a prototype LLVM backend for Bigloo Scheme.
For Clojure: there's Rhine, which is a Clojure-inspired lisp.
There's a very small and apparently unoptimised Scheme compiler here:
http://www.ida.liu.se/~tobnu/scheme2llvm/
Taking your question literally,
Writing compilers is hard.
A poor implementation like the one linked above can block new implementations. People going to the LLVM page see that there's a Scheme already, and don't bother writing one.
There's a limited number of people who write and use Scheme (I'm one, not a hater, btw).
There are lots of existing Scheme intepreters and compilers and there's not a screaming need to have a new one.
There's not an immediate, clear benefit to writing a new interpreter using LLVM. Would it be faster, easier, more flexible, better in some way than the other dozens of Scheme implementations?
The LLVM project went with another language (C) to demo their technology, and haven't seen a need to implement a lot of others.
I think that it could be a lot of fun for someone to build an LLVM-based Scheme compiler. The Scheme compilers in SICP and PAIP are both good examples.
Maybe I'm completely misunderstanding the question or context, but I believe that you could use ECL, which is a Common Lisp that compiles down to C, and use the Clang compiler to target LLVM (instead of GCC).
I'm not sure what (if any) benefit this would give you, but it would give you a Lisp running on LLVM =].
One thing to keep in mind is that many of these implementations have C FFIs and native-code compilers that significantly predate LLVM.
CL-LLVM provides Common Lisp bindings for LLVM. It takes the FFI approach, rather than attempting to output LLVM assembly or bitcode directly.
This library is available via Quicklisp.
mocl is a compiler for a relatively static subset of Common Lisp. It compiles via LLVM/Clang.
there's not (to my knowledge) a single
popular scheme/lisp on LLVM
Currently, llvm-gcc is the nearest thing to a popular implementation of any language on LLVM. In particular, there are no mature LLVM-based language implementations with garbage collection yet. I am sure LLVM will be used as the foundation for lots of exciting next-generation language implementations but that will take a lot of time and effort and it is early days for LLVM in this context.
My own HLVM project is one of the only LLVM-based implementations with garbage collection and its GC is multicore-capable but loosely bound: I used a shadow stack for an "uncooperative environment" rather than hacking the C++ code in LLVM to integrate real stack walking.
There is a Scheme2LLVM, apparently based on SICP:
The code is quite similar to the code in the book SICP (Structure and Interpretation of Computer Programs), chapter five, with the difference that it implements the extra functionality that SICP assumes that the explicit control evaluator (virtual machine) already have. Much functionality of the compiler is implemented in a subset of scheme, llvm-defines, which are compiled to llvm functions.
I don't know if it's "good".
GHC is experimenting with a scheme backend and getting really exciting preliminary results over their native code compiler. Granted, that's haskell. But they've recently pushed new changes into LLVM making tail calls easier IIRC. This could be good for some scheme implementation.

Developing an operating system for the x86 architecture [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am planning to develop an operating system for the x86 architecture.
What options of programming languages do I have?
What types of compilers are there available, preferably on a Windows environment?
Are there any good sources that will help me learn more about operating system development?
Is it better to test my operating system on a Virtual Machine or on physical hardware?
Any suggestions?
For my final year project in collage I developed a small x86 OS with a virtual memory manager, a virtual file system and fully preemptive multitasking. I made it open source and the code is heavily commented, check out its source forge page at:
https://github.com/stephenfewer/NoNameOS
From my experience I can recommend the following:
You will need x86 assembly language for various parts, this in unavoidable, but can be kept to a minimum. Fairly quickly you will get running C code, which is a proven choice for OS development. Once you have some sort of memory manager available you can go into C++ if you like (you need some kind of memory manager for things like new and delete).
No matter what language you choose you will still need assembly & C to bring a system from boot where the BIOS leaves you into any useable form.
Ultimately, the primary language you choose will depend on the type of OS you want to develop.
My development environment was the Windows port of the GNU development tools DJGPP along with the NASM assembler. For my IDE I used IBM's Eclipse with the CDT plugin which provides a C/C++ development environment within Eclipse.
For testing I recommend BOCHS, an open source x86 PC emulator. It lets you boot up your OS quickly which is great for testing and can be integrated into eclipse so you can build and run your OS at the push of a button. I would also recommend using both VMWare and a physical PC occasionally as you can pick up on some subtle bugs that way.
P.S. OS development is really fun but is very intensive, mine took the best part of 12 months. My advice is to plan well and your design is key! enjoy :)
Language and compiler depend entirely on what you're attempting to accomplish. I would suggest, though, that you might be approaching the problem from too low a level.
There are materials out there on operating system fundamentals. MIT has OpenCourseware on the subject. Read through Andrew Tannenbaum's Operating Systems series, and look at things like Minix.
Get an idea for what's out there. Start tinkering with things. Borrow ideas, and see where they go. You can reinvent the wheel if you really want, but you'll learn more by building on the works of others.
It doesn't really matter, what language you choose. If the language is Turing-complete, then you can write an OS in it.
However, the expressiveness of the language will make certain kinds of designs very easy or very hard to implement. For example, the "liveliness" and dynamism of the old Smalltalk OSs depends on the fact that they are implemented in Smalltalk. You could do that in C, too, but it would probably be so hard that you wouldn't even think about it. JavaScript or Ruby OTOH would probably be a great fit.
Microsoft Research's Singularity is another example. It simply couldn't be implemented in anything other than Sing#, Spec# and C# (or similar languages), because so much of the architecture is dependent on the static type safety and static verifiability of those languages.
One thing to keep in mind: the design space for OSs implemented in C is pretty much fully explored. There's literally thousands of them. In other languages, however, you might actually discover something that nobody has discovered before! There's only about a dozen or so OSs written in Java, about half a dozen in C#, something on the order of two OSs in Haskell, only one in Python and none in Ruby or JavaScript.
Try writing an OS in Erlang or Io, and see how that influences your thinking about Operating Systems!
There is an OS course offered at the University of Maryland that utilizes GeekOS. This is a small, extensively commented OS designed for educational purposes which can be run using the Bochs or QEMU emulators.
For an example of how it is used in a course, check out a previous offering of the course at the class webpage. There, you will find assignments where you have to add different functionality to GeekOS.
Its a great way to get familiar with a small and simple OS that runs on the x86 architecture.
You might want to look up XINU. it's a tiny OS for x86 that isn't really used for anything other than to be dissected by students.
Use ANSI C, and start off with an emulator.
When you port over to a real machine, there will be some assembler code. Context switching and interrupt handling (for instance) is easier to write in assembler.
Andy Tannenbaum has written a good book on OS. Many other good ones exist.
Good luck! There is nothing quite like haveing written your own OS, however small.
Also check out the OSDev.org which have all information you need to get started.
I've done that once for a 386SX, which was on a PCI board. A good source on how to start a X86 cpu in protected mode is the source code of linux. It's just a few assembly statements. After that you can use gcc to compile your C code. The result is objectcode in ELF format. I wrote my own linker, to make a program out of the objectcode. And yes, it worked! Good luck.
Be sure to check out the answers to my question:
How to get started in operating system development
Without a doubt, I'd use Ada. It's the best general-purpose systems-programming language I have come across, bar none. One example, Ada's much better for specifying bit layout of objects in a record than C. Ada also supports overlaying records on specific memory locations. C requires you to play with pointers to acheive the same effect. That works, but is more error-prone. Ada also has language support for interrupts.
Another: Safety. Ada defaults to bound checking array assignments, but allows you to turn it off when you need it. C "defaults" to no bound checking on arrays,so you have to do it yourself manually whenever you want it. Time has shown that this is not the right default. You will forget one where it is needed. Buffer overflow exploits are the single most common security flaw used by crackers. They have whole websites explainng how to find and use them.
As for learning about doing this, the two books I'm aware of are XINU (Unix backwards, nothing to do with Scientology), and Project Oberon. The first was used in my Operating Systems graduate course, and the second was written by Nikalus Wirth, creator of Pascal.
If you are making a full OS, you will need to use a range of languages. I would expect Assembly, C and C++ at the very least.
I would use a Virtual Machine for most of the testing.
C most probably...all major OS-es have been written in C/C++ or Objective-C(Apple)
If you want write an OS then you need a couple of people. A OS can not write a single people. I think it is better to work on existing OS projects
Reactos --> C, Assembler
SharpOS --> C#
JNode --> Java
This is only a short list of OS projects. How you can see there is a project for every possible language.