Services in and around open source compilers.
Starting around 2015, Cosmic also started working on open source compilers and related tools with selected Partners who wanted to
take advantage of our knowledge and experience as a compiler producer and seller and apply it to their open source based product
(gcc, llvm and similar).
If you think you might need help on your open-source compiler, below is a list of possible services that we can offer: if you are brave
enough to read after the first paragraph, don't hesitate to get in touch to discuss your case: we are usually happy to make a small test
project before commiting to work together.
Complete back end development.
If you have, or planning to have, a specific architecture/chip for which there is no compiler yet, we can develop a full gcc (or llvm) back end
for you, in such a way that the users of your architecture will have a well-known, free toolchain for their software development needs.
Benchmarking
Running benchmarks is not too difficult: understanding the results and explain differences with other architectures (or with different compilers /
compiler versions) in a consistent way is way more challenging, but that's a must-have if you want to achieve the best possible optimization.
What we can do for you is running your favorite benchmarks (either commercial/open source, like Coremark and similar, or your own code/examples),
either in simulation or on dedicated hardware (usually an fpga board), extract the numbers, and explain them by also extracting the most significant
assember sequences that are responsible for that numbers: that is the ultimate way to understand why the numbers are the way they are, and
what could be done to improve them (either from the performance/speed or code density point of view).
Optimization
The main open source compilers are very well optimized in their general parts/passes, but the final performance of your toolchain is (also)
heavily influenced by the quality of the backend: if you think the performance of your compiler can be improved (maybe generally, because
the benchmarks are not as good as you hoped, or more specifically, because you have seen the assembler generated and it is not yet optimal)
that's what we have been doing for the last 3 decades !
Give us an example of what you think can be improved and we will analyse it together: the first thing to check is if the use of the existing
ISA (the assembler instructions) is optimal or not: if it is, there is nothing to do on the compiler, but we can still make suggestions for
improving the ISA in the next versions (this can go as far as producing a virtual toolchain with new/modified instructions to check the final
result without committing to a new silicon design).
If the assembler is not optimal, we can usually say if it would be "reasonably simple"
to improve the backend to achieve the desired result, or if that would require very complex modifications that would possibly break
something else.
Libraries (including vectored/parallel versions)
Some application specific libraries need to achieve the absolute maximum possible performance (think of te ARM CMSIS and the RISCV equivalent
as examples): this usually requires to write them in assembler, or with a complex mix of C and Assembler, and test them until the last
possible cycle has been squeezed out.
This kind of library gets even more complex when the processor supports some form of parallel computation (SIMD, Vectors..) or specific instructions that
are usually way too complex to be managed 100% in C (as of 2025).
Writing and maintainig these libraries is something we can help with: your Customers can then use the libraries as they are (if you decide
to only provide them in binary form) or as a base for their own versions of performance-critical routines.
Testing, maintaining.
These activities never get much attention, but we all know no serious toolchain can make light work of them.
Keeping up with mainline gcc versions is a project in itself; although gcc makes a very good work of being backward compatible as much as
possible, once a year you get in a situation where you try to make your backend work with the latest gcc trunk (the generic part) and
hope nothing breaks.. adapting to new APIs is sometimes tricky, and even when you get the whole thing to build, there are tons of tests
and regression suites to run..
What we can do here, in addition to make the work for you (we have special hw setups for these 'heavy' tasks), is to help classify
testsuite fails according to their relevance: we have developped some special (small) tools to help ignore irrelevant fails (tipically tests that use features not all architectures have) while
at the same time being sure not to miss out any real fail because they are drowned into thousands of irrelevant messages.
We also have our own testsuites, that can be added to those provided with the open source for extra safety and extended reporting purposes.
Documenting, reporting
When you work IN the compiler, it is sometimes difficult to get an exact perception of what people working WITH the compiler (the final
users) experience : all the best and pointy optimizations will be lost to them if they start struggling with some points that might
appear obvious to experts, but are never quite so when you start.
Proper documentation is essential for a happy final user experience: detailed documentation is usually extensive, but is it really useable
with a reasonable effort?
What we like to do is to add to the official doc at least a very detailed Getting Started, prefereably in video format, where the final
users sees a blank PC (same as they have) and all the steps necessary to download, install and run the toolchain on it, usually going
as far as building and simulating at least one example; with this format, no risk of missing some steps and the Out Of The Box experience
is usually positive, which is a very important factor.
More technical documentation have its own issues: the autogenerated docs are very good as a reference manual, but often something additional
is needed, in the form of Application Notes (or similar) that explain the context and provide examples of how to use certain features:
we can help produce this additional documentation for you (in various formats; pdf, website, video..) and we
believe final users are quite happy with our docs :)
|
|
 |
|
|
Product Quick links
General Info
