Hacker News Reader

Hacker News

Comment by ducktective | Hacker News Reader

Parent Full thread

ducktective

Thanks for posting.

> Translating DOOM from C to V

Like, you can literally translate a C project to V without any manual intervention?

View on HN

Exactly.

This isn't a criticism, but what's the purpose of using c2v? As in, anything outside c2v just to compile it. The example of DOOM is taking the C code, converting it to V, then compiling it (which internally converts V to C before passing it off).

Generating V wrappers on top of C libraries in order to use them. Otherwise all functions and types would have to be manually converted.

Migrating older projects from C to a nicer newer language.

By moving from C to V you get rid of complex makefiles, headers (you get nice clean modules instead), you get a modern stdlib with strings etc (although C strings aren't converted to V strings by C2V yet), much easier cross compilation, etc.

How do you handle function-like macros and concatenation? Also, both D and Zig seem to have switched to including a full C compiler instead due to issues with translating C source wise, is that a possible direction for this in V or is the source translation good enough?

Macros are unwrapped by Clang when generating C AST.

No plans to support C compilation for now, translation works well enough.

Was it tested on very huge code base like say, the Linux kernel?

DOOM is big but not huge.

So not yet.

But we are planning to translate SQLite soon and yes the Linux kernel at some point.

Yes I didn't mean to down size the impressiveness of translating DOOM, congratulation for that.

I was just wondering to which scale it would stretch properly.

Thanks for your replies.

Linux kernel might be a tricky one with all the inline assembly code.

Luckily V supports inline assembly code! It's used a lot in Vinix.

A use case would be converting an existing c codebase to v and then continuing development in v, rather than c.

I think this is very good for legacy C projects specifically that are no longer being worked on, to breath new life into them and easier coding.

For libraries this can be useful if it means that you don't need to deal with a separate C toolchain in the build process. Instead you just bundle a copy of the library transpiled from C.

If it works, devs can move to a safer language for future development of the project. Anyways, code as a sacred artifact perspective needs to go - by that I mean, having tools to modify/convert and answer questions about code much more easily. May be with AI that would finally be possible.

I presume the intention is that V will be compiled natively eventually, not via C.

Yes, there's our own fast native backend, about as fast as tcc. But it can't compile V yet.

It will never be as optimized as cc -O2 though, and it will never be as portable as C, so C will always stay an option.

Reply on news.ycombinator.com