When generating code, in what language should you generate?

I have worked on several products that use code generation. This is apparently the only way to achieve both a high degree of customization and a high execution speed.

The disadvantage is that we require users to install the compiler (primarily on MS Windows).

This was an ongoing headache because vendors such as MS maintain obsolete compilers, and some users have more than one compiler.

We are considering using GNU C and possibly C ++, but even there are problems with the permanent version.

I considered generating assembly language to get out of the treadmill with the compiler version, but assembly languages ​​all depend on the machine.

Ideally, there would be some way to create the generated code that would be flexible, work quickly and not expose us to the whims of third-party suppliers.

Perhaps I missed something simple, like Java. Any ideas would be good. Thanks.

+6
code-generation
source share
12 answers

If you are considering C and even assembler, first take a look at LLVM: http://llvm.org

+8
source share

I may not have enough context, but can you just bind yourself to a specific version? For example, .NET 2.0 can be installed next to .NET 1.1 and .NET 3.5, as well as other versions that will appear in the future. So while your code is using a specific version of the compiler, what's the problem?

+3
source share

I considered generating assembly language to get out of the treadmill with the compiler version, but assembly languages ​​all depend on the machine.

This will be called the compiler :)

Why don't you stick with the C90 ?

I have not heard of serious gcc standards violations if you are not using extensions.

And you can always distribute a specific version of gcc along with your product, say 4.3.2 , giving users the option to use their own compiler at their own risk.

As long as all the code is generated by you (i.e. you do not embed your instructions in another code), there should be no problems when testing this version and using it to compile your libraries.

+3
source share

If you want to generate asm code, you can take a look at asmjit .

+3
source share
+2
source share

One option is to use a language / environment that provides access to the compiler in code; For example, here is a C # example .

+2
source share

Why not send a GNU C compiler with a code generator? Thus, you have no problems with the version, and the client can constantly generate code that can be used.

+2
source share

It looks like you are looking for LLVM.

+2
source share

I would stick with the language you use to create this language. You can generate and compile Java code in Java, Python code in Python, C # in C # even LISP in LISP, etc.

But it is unclear whether such languages ​​are enough for you. For maximum speed, I would like to generate C ++ and use gcc to compile.

+1
source share

Why not use something like SpiderMonkey or Rhino (Javascript support in Java or C ++). You can export your objects to Javascript namespaces, and your users do not need to compile anything.

+1
source share

It may be too late. but here are my two cents. embed in a translator program for a language such as lua / scheme. and generate code in that language.

+1
source share

In the spirit of “maybe it's not too late to add my 2 cents”, as with @Alvin’s answer, here’s what I would think: if your application is designed for several years, it’s going to face several changes in the operation of applications and systems.

For example, let's say you thought about it 10 years ago. Then I watched Dexter, but, in my opinion, you really have memories of how it was then. From what I can say, multithreading was not a big problem for 2000 developers, and now it is. Therefore, Moore's law interrupted them. Prior to this, people did not even care about what would happen in Y2K.

Speaking of Moore’s law, processors really become quite fast, so perhaps some optimizations will not even be so necessary. And, perhaps, the array of optimizations will be much larger, some processors get optimization for several server elements (XML, cryptography, compression and regular expression! I am surprised that such things can be done on the chip), as well as spend less energy (which is probably very important for war hardware ...).

My point is that focusing on what exists today as a platform for tomorrow is not a good idea. Make it work today, and it will certainly work tomorrow (backward compatibility is especially valuable to Microsoft, Apple is not bad, and Linux is very liberal in making it work the way you want).

There is, yes, one thing you can do. Attach your technology to something that simply won't (probably) die, like Javascript. I'm serious, Javascript VMs are becoming terribly efficient these days, and they just get better, plus everyone loves it, so it's not going to suddenly disappear. If you need higher performance / features, perhaps targeting a CRL or JVM?

I also believe that multithreading will become more and more a problem. I have a feeling that the number of processor cores will have Moore's own law. And the architecture is likely to change in terms of cloud noise.

PS: In any case, I believe that C optimization of the past is still quite applicable with modern compilers!

+1
source share

All Articles