On Sat, 14 May 2022 04:31:24 -0500 Rob Landley <r...@landley.net> wrote:
> On 5/11/22 11:55, Ivo van Poorten wrote:
> > https://github.com/rui314/chibicc
>
> Yeah, I saw your poke about that through the old qcc mailing list. :)
Haha, wasn't sure if it was still read, so I thought I'd post a link
here, too. Wider audience, etc..
> kconfig/conf.c:38: static char nohelp_text[] = N_("Sorry, no help
> available for this option yet.\n");
> ^ expected ','
This looks like a cpp bug, assuming N_ is a macro.
> generated/obj/lib_args.o unknown argument: -funsigned-char
> make: *** [Makefile:19: toybox] Error 1
>
> There are some todo items, it seems. (Also, what targets does it
> output code for? Hmmm, codegen.c looks like it's hardwired to x86?
chibicc could work like tinycc, having several codegen-*.c, and compile
separate binaries for each target. Looks like it now solely targets
x86_64.
> My
> whole qcc idea was to glue qemu's tcg to the tinycc front end to get
> all the targets qemu supports, but these days I think that's waaaaay
> overkill...)
Probably. x86_64, arm64 and risc-v should cover most use cases.
> Also, this is a compiler but not an assembler or linker. Or strip,
> nm...
>
> http://landley.net/hg/qcc/file/tip/todo/commands.txt
> http://landley.net/hg/qcc/file/tip/todo/todo.txt
>
> (My tinycc rewrite was going to make a multiplexer out of it so it
> ran as the appropriate tool when called by the appropriate name.
> Alas, stopped working on that in something like 2008?)
I remember. I have been "following" you for a while ;) Possibly
from since around the time you forked tcc and got the BSD license
permission from Bellard.
> Do you think it's worth feeding the chibicc guy bug reports about
> trying to build stuff with it?
I'm not sure. The github repo hasn't been updated in 17 months, and
there is no book to be found yet.
But I found his earlier 2020 book. In Japanese:
https://www.sigbus.info/compilerbook
Perhaps one bug report to see if he's responsive?
> A chibicc/lld pair would be interesting (apparently the same guy
> wrong both),
Yes. Only as would be missing (as as in cc/as/ld). You mentioned strip,
nm, ... (objdump?) but those are not the first priority. Perhaps ld
could even have (or already has?) an option that strip becomes (almost)
obsolete?
> but this STILL hits
> the problem that llvm's libgcc replacement is apocalyptically bad:
>
> https://landley.net/notes-2021.html#28-07-2021
>
> (You wouldn't think this was hard! And yet...)
>
> The main reason Linux ate Minix is Andrew Tanenbaum wanted a teaching
> tool, and rejected patches that complicated his simple/clear project
Totally agree. I had classes from him back when Minix 2 was a thing,
but we also got Minix 1 floppies for the Atari ST and MSDOS :) I think
it was all about the book deal in the end.
Minix 3 was a step forward, as it was written from scratch and didn't
suffer the license dependencies that Minix 2 still had, but it failed to
really catch on. On the other hand, Intel apparently put it in their
"spy" part of their CPUs ;)
> Rob
Regards,
Ivo
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
