`ppci-cc hello.c -o hello; ./hello` should "just work"

[windelbouwman]

The scenario:

ppci-cc hello.c -o hello; ./hello should "just work" (tm) to give a better out of box experience.

See #24 for an initial discussion about this.

Questions here:

• Use a C library?
• What C runtime to use?
• How to deal with windows, linux, mac support?

[pfalcon]

As I mentioned elsewhere, the question of standard and runtime support libraries is a big task, which is also not really of "research" and "computer science" type of task (unlike for example IR, optimizations on it, codegeneration, etc). Instead, it's ~~gruntwork~~ mere engineering.

Of course this still would need to be resolved, just the same as similar "mere engineering" tasks for project building, linking, executable file generation were resolved (not completely, but "noticeably" for sure).

So, I guess the top question is the usual one:

1. Whether to do work from scratch, or,
2. Whether to reuse existing project.

One of the big points of https://github.com/windelbouwman/ppci-mirror/issues/11 (I'm nor sure if it's pronounced explicitly enough) is that it won't do to make everything from scratch - that's sisyphean effort with very slow progress, and leading only to NIH land. So, with full understanding that a quick prototype/mockup is easier to do from scratch, I'd recommend to put energy into leveraging/adaptation of an existing projects instead.

[pfalcon]

With that intro, specific suggestions:

Use a C library?

Yes. Newlib is a well-known libc implementation which is also not too bloated (used in deeply embedded projects). Note that I have an impression that recent months, I see another libc project popping up in my github feed like every month. That can be a typical turing tarpit though - some lib may be smaller and easier to leverage, but then turns out that it's incomplete, buggy, and need constant fixing.

What C runtime to use?

LLVM/Clang folks once had a same question, and it take even 10 years them to make a well complete and shiny librt. We should try to reuse it as far as possible (note that I'm personally not familiar with it).

How to deal with windows, linux, mac support?

Ughh, another tarpit. I'd say, keep doing it like it is now: keep PPCI cross-platform, but concentrate on generating one executable format well (ELF). Windows people, besides a usual option of running a Linux VM, can use WSL nowadays. Mac people can use an emulator or contribute support for MachO or whatever they use nowadays. And MacOSX is largely posix compatible, so libc efforts should just help with Mac support anyway (I mean, in larger scope than just stuff like string.h, which will also help Windows automagically).

[pfalcon]

But again, libc/librt matters are big. There's still much lower-hanging fruit:

ppci-cc hello.c -o hello; ./hello should "just work"

So, from this, immediate thing what's missing is ppci-cc call ppci-objcopy to produce a real platform executable. And I'd say, rather ppci-ld should do it, as usual. No, .oj format is cute and fine. It's just that ld's output should be a platform executable by default. Current behavior (producing another .oj) should be ld -r.

[windelbouwman]

I added the link option -r. Leaving the option out, generated an elf file with objcopy. The makefile example you made can use this, and skip the objcopy step.

[pfalcon]

Leaving the option out, generated an elf file with objcopy.

Great, thanks! With winter holidays over, it will be more latency for me to look into ppci, but I hope to update the makefile example on weekend.

[pfalcon]

I think there's a good progress on the title of this ticket. The next logical step is: just the same as ppci-ld was made to run ppci-objcopy automagically, just the same ppci-cc should call ppci-ld, unless -c option is given.

Just to plan ahead, the next step after that is implementing C startup file (crt0.s/crt1.s, so I think in our case, we'd better not go for premature optimization and have it as crt1.c). This file would live somewhere in the PPCI codebase (yet would be easy enough for users to discover), and would be pulled automatically by ppci-cc when linking a C app (and ppci-cc also should be able to act as a linker, i.e. when it's called like ppci-cc o1.o[j], o2.o[j] -o foo, it should do the expected, which is pass all those files down to ppci-ld, augmenting the list with crt1.o, later with -lc, and with other aux files needed (like link script)).

And only then the question of the C stdlib raises in the full height.