Re: [Tinycc-devel] [PATCH v2] arm-asm: Add vcvt
Danny Milosavljevic writes:
Hello!
> as of commit 24c94fff09ea21f2e70b575256824e4648124aad on tinycc mob, arm-asm
> is finished. I've added all that one could reasonably want in
> lowest-common-denominator ARM assembly.
Oh my, that's...Amazing!!
Now...it would be grand if we can get GNU Mes in to build this, or if we
really must, patch "bootstrappable-tinycc"*); then we can remove
fake-asm snippets hacks like these
--8<---cut here---start->8---
#if !__TINYC__
void
_start ()
{
asm (
"movr0,#0\n\t"
"mov%0,r0\n"
: "=r" (__stdin)
: //no inputs ""
);
[..]
#else //__TINYC__
void
_start ()
{
int *in = &__stdin;
int *out = &__stdout;
int *err = &__stderr;
char ***env = &environ;
/* environ = argv + argc + 1 */
__asm__ (".int 0xe59b000c\n"); //ldr r0, [fp, #12]
__asm__ (".int 0xe28b1010\n"); //add r1, fp, #16
[..]
--8<---cut here---end--->8---
from the "Reduced Binary Seed" **) bootstrap; as the above does not
really count as "source code": The GPL defines this as the preferred
form of the work for making changes in it.
Greetings,
Janneke
*) https://gitlab.com/janneke/tinycc/-/tree/mes-0.23
**) https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Danny Milosavljevic writes: Hi Danny, Grishka! > On Fri, 08 Jan 2021 08:16:29 +0100 > grischka wrote: > >> But no such thing happens in this case. The 'ptr' in init_putv() >> comes from >> >> ptr = sec->data + c; >> >> and it seems that if tcc is doing the right thing then 'c' cannot >> be misaligned, and if malloc/realloc on that system is doing the >> right thing, then sec->data cannot be misaligned either. So...? > > How does tcc allocate dynamic memory? I've tried to find out, but > tcc_malloc is defined to be "use_tcc_malloc", which I don't find > anywhere. Does it use libc malloc for that ? > > (With MEM_DEBUG defined, tcc_malloc_debug seems to use malloc. But > what about without MEM_DEBUG defined ?) > > If so, is libc malloc supposed to ensure alignment of allocated memory? > > According to https://man7.org/linux/man-pages/man3/malloc.3.html yes. > > @Janneke: So our mes libc malloc should be aligning the stuff--but it's not > doing it. So it's a bug in our libc. Beautiful! Maybe this explains other differences we saw between aarch64-linux and arm-linux? Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
> Jan Nieuwenhuizen wrote: Hello Arnold! >> to the gawk-mesbot0 recipe also fixes "inc.awk". The pre >> increment/decrement code looks like this: >> >> --8<---cut here---start->8--- >> *lhs = make_number(lval + >> (tree->type == Node_preincrement ? 1.0 : -1.0)); >> >> --8<---cut here---end--->8--- > > What in the world? That looks like gawk 3.x code, which is > terribly ancient. What project is still using a version that old? We are removing binary seeds from the GNU Guix package graph. The binary packages in Guix form an acyclic graph and at the bottom of the graph we originally had binutils, glibc, gcc, bash, coreutils&co (gawk, gzip, sed, tar, ...). Since 2016 we have been working to eliminate those binary seeds. For a complete overview and more background see https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/ https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ but what we did is remove all those, replacing them by Stage0, GNU Mes, tinycc...and multiple versions of ancient GNU tools. Using ancient tools is less than great, we are using those because "it works" or rather, we didn't succeed as yet using newer versions. Often, newer versions of a software are more demanding in their requirements and are less bootstrappale. In other cases, ancient software does not build with newer tools, because they are more strict. > Arnold > (The gawk maintainer) Thanks for reaching out! Sadly I do not have more concrete information (let alone a bug report or feature request) for you yet, other than that we are using gawk-3.0.0, lateron v3.1.8, and only finally v5.0.1. Simalarly for other tools. The biggest hudle was bootstrapping glibc and gcc, as you can imagine. Currently, we start with gcc-2.95.3 and I would very much like to target gcc-4.6.4 directly instead. For a tool as gawk, it would be great to be able to the latest greatest! Greetings, Janneke (GNU Mes author) -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
cut here---end--->8---
at least to get tcc's ARM binaries to run on Aarch64-Linux. Is this
related; iow, could it be that this "fix" for Aarch64 break ARM?
> tinycc does have:
>
> /* reserve at least 'size' bytes aligned per 'align' in section
>'sec' from current offset, and return the aligned offset */
> ST_FUNC size_t section_add(Section *sec, addr_t size, int align)
> {
> size_t offset, offset1;
>
> offset = (sec->data_offset + align - 1) & -align;
> offset1 = offset + size;
> if (sec->sh_type != SHT_NOBITS && offset1 > sec->data_allocated)
> section_realloc(sec, offset1);
> sec->data_offset = offset1;
> if (align > sec->sh_addralign)
> sec->sh_addralign = align;
> return offset;
> }
>
> But that's not used for init_putv.
OK.
> And section_reserve, which is used, doesn't care about alignment at all.
>
> (it seems there's a reserved part and a data part in each section, and
> it holds that the data part elements are aligned--but the reserved part
> elements are NOT aligned. I don't see how sec->data would be aligned
> by the dynamic memory allocator either)
>
> Other notes:
>
> tccgen.c even has this:
>
>>/* XXX: when cross-compiling we assume that each type has the
>> same representation on host and target, which is likely to
>> be wrong in the case of long double */
>
> Yeah, and even when NOT cross-compiling, the alignment is wrong--which means
> it sometimes won't work at all on ARM, depending on luck.
>
> As a workaround, we can patch tcc to instead do the assignments on elements
> on the stack and then copy those over, instead of doing
>
> *(double *)ptr = vtop->c.d
>
> (the latter of which emits VFP instructions that expect double-aligned
> pointers).
So alignment should be fixed, but that's more work and you propose a
workaround, right? I'm struggling to understand the implications of
this last bit...guessing you will be preparing a patch for the mes-0.23
branch of our "bootstrappable tinycc"? Oh, and we need that same patch
for plain tcc-0.9.27, for "tcc-boot" of course!
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH 00/16] Add ARM inline assembler
Danny Milosavljevic writes: Hello! > This patchset adds an ARM inline assembler. That's awesome! This is going to make the ARM bootstrap of tinycc so much nicer. In other news, I finally got setjmp/longjmp to work with tcc. Because has a different function pre- and post-amble than gcc it needed some $fp/$sp juggling. With this we just may have tinycc bootstrap for ARM done, or have a clearer view of the next problem. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Hello! Does anyone maintain this still?
David Smith writes: Hi David, > I’m on a mission this quarter to add a new old arch. Lots to learn. Interesting...I am currently looking into ARM and power9 ports of the bootstrap. Anyway, your question reminded me the difficulties I had to finding the home of TCC development; and I realised that I have possibly made that worse. Sorry! So I have added an extra patch to README https://gitlab.com/janneke/tinycc explaining that you are looking at a bootstrappable tcc fork and adding a pointer to https://repo.or.cz/tinycc.git HTH, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Hello! Does anyone maintain this still?
David Smith via Tinycc-devel writes: Hello, > I noticed a mes/gnu 0.21 branch. How is that related to mob? > > https://gitlab.com/janneke/tinycc/-/commits/mes-0.21/ This is the bootstrappable fork of tinycc. It's basically a forked off a somewhat arbitrary tinycc git development commit some three years ago (307b7b183d4ee56e74090b0e525d6a587840e31f) and adds about 12 patches cee58e0 build: Support building from bootstrap-mes. 39de356 bootstrappable: Force static link. 2b6271d bootstrappable: Work around MesCC bug. 379c62d bootstrappable: add tcc.h include guards to include location. 274bd06 bootstrappable: Handle libtcc1.a. 6ae9aa4 bootstrappable: Skip tidy_section_headers. a130ce1 bootstrappable: HAVE_FLOAT. de906df bootstrappable: HAVE_BITFIELD. 540ba0b bootstrappable: HAVE_LONG_LONG. 306f677 bootstrappable: Work around Nyacc-0.80.42 bug. 9c97705 build: bootstrap build scripts. 584478f bootstrappable: Remove non-free grep test. of which only three are really interesting: the HAVE_* patches that allow for stepwise introduction of bitfields, doubles/floats and long longs. I'm hoping to get rid of the need for this fork some time. Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] __builtin_va_* builtins missing
Daniel Wingerd writes: > I'm working on getting musl to build using TCC and the first problem I > encountered was that TCC is missing __builtin_va_* builtins. I suspect this is on x86_64? FWIW, I have finally managed to bootstrap*) TCC on i686-linux using the Mes C Library and a pretty simplistic stdarg+). Greetings, janneke *) http://joyofsource.com/reduced-binary-seed-bootstrap.html +) http://git.savannah.gnu.org/cgit/mes.git/tree/include/stdarg.h -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Mes 0.16 released
I am pleased to announce the release of Mes 0.16, representing 27 commits over 2 weeks. A most annoying ELF header bug was fixed that suddenly had all Mes binaries segfault before entering `_start' on Linux 4.17 and later. We now have binutils-2.20.1 and gcc-4.1.0, both compiled with gcc-2.95.3 and glibc-2.2.5. This reduced-binary-seed bootstrap still depends on these bootstrap binaries: BOOTSTRAP-GUILE, flex, bash, bzip2, coreutils, diffutils, gawk, grep, gzip, make, sed, tar, on the small binary seeds: tinycc-seed, mescc-seed and on the mes.M1 ASCII seed. Next targets: - build a Gcc 4.7 and Glibc 2.23 - upstream the x86 Mes bootstrap to GuixSD - reduce the 1MB ASCII M1 seed to ~5000 LOC/~100KB of M2 source - revive Gash: a posix shell for Guile to reduce the bootstrap binary dependencies - and/or otherwise reduce the bootstrap binary dependencies Packages are available from Guix's wip-bootstrap branch. * About Mes[0] aims to help create full source bootstrapping for GuixSD[1] as part of the bootstrappable builds[2] effort. It currently consists of a mutual self-hosting Scheme interpreter prototype written in C and a Nyacc-based C compiler written in Scheme. This C prototype is being simplified[3] to be transpiled by M2-Planet[4]. The Scheme interpreter prototype (mes.c) has a Garbage Collector, a library of loadable Scheme modules-- notably Dominique Boucher's LALR[5], Pre-R6RS portable syntax-case[6] with R7RS ellipsis, Matt Wette's Nyacc[7], Guile's PEG[8] --and test suite just barely enough to support a simple REPL and simple C-compiler: MesCC. Mes+MesCC can compile an only lighty patched TinyCC[9] that is self-hosting. Using this tcc and the Mes C library we now have a reduced-binary-seed bootstrap for the gnutools triplet: glibc-2.2.5, binutils-2.20.1, gcc-4.1.0. Mes is inspired by The Maxwell Equations of Software: LISP-1.5[10] -- John McCarthy page 13, GNU Guix's source/binary packaging transparency and Jeremiah Orians's stage0[11] ~500 byte self-hosting hex assembler. * Download git clone https://gitlab.com/janneke/mes wget https://gitlab.com/janneke/mes/-/archive/v0.16/mes-0.16.tar.gz Mes runs from the source tree and can also be built, packaged and installed in Guix[SD] by the usual guix package -f guix.scm * Get informed, get involved Join #bootstrappable on irc.freenode.net. * Changes in 0.16 since 0.15 ** Core *** Support building with tcc, including Mes Lib C in-line assembly. *** core:execl now supports 1000 arguments. ** MesCC *** Mes Lib C now bootstraps glibc-2.2.5, binutils-2.20.1, gcc-4.1.0. *** MesCC binaries now run on Linux 4.17 too, i.e. survive Linus' new `sane mmap limits.' *** MesCC now runs with mescc-tools 0.5 (no = in long options). 3 new C test 88-strrchrc, 97-fopen.c, 98-fopen.c. ** Noteworthy bug fixes *** strrchr now stops when it reaches start of string. *** fopen now return 0 upon failure. Supports binutils' hack: fd=-2 means `cached'. *** vfprintf, vsprintf now support precision and width on integers strings better. *** fread now produces ungetc'd chars too. *** memcmp now supports comparing 0 bytes, supporting binutils. *** The unused ELF header data section, identical to the text section, has been removed. Greetings, janneke [0] https://gitlab.com/janneke/mes [1] https://www.gnu.org/software/guix [2] http://bootstrappable.org [3] https://github.com/oriansj/mes-m2 [4] https://github.com/oriansj/m2-planet [5] https://github.com/schemeway/lalr-scm [6] https://www.cs.indiana.edu/chezscheme/syntax-case/old-psyntax.html [7] https://www.nongnu.org/nyacc [8] https://www.gnu.org/software/guile/docs/master/guile.html/PEG-Parsing.html [9] https://gitlab.com/janneke/tinycc [10] http://www.softwarepreservation.org/projects/LISP/book/LISP%25201.5%2520Programmers%2520Manual.pdf [11] https://github.com/oriansj/stage0 -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Using tinycc for full source bootstrapping
Hi! Are you willing to consider discussing/taking patches that reduce the variety and complexity of C constructs used in TinyCC source code? I have a list of about 20 unpolished patches[0] for constructs like: comma operator -p[0] = x & 255, p[1] = x >> 8 & 255; +p[0] = x & 255; p[1] = x >> 8 & 255; or (heterogeneous) initialzer lists -uint8_t buf[1000], *p = buf; +uint8_t buf[1000]; +uint8_t *p = buf; or function return derefencing -v = tok_alloc(astr.data, astr.size - 1)->tok; +TokenSym *tk = tok_alloc(astr.data, astr.size - 1); +v = tk->tok; or complex field access -return table_ident[v]->sym_define; +TokenSym *t = table_ident[v]; +Sym *s = t->sym_define; +return s; or even struct by value assign -vtop->type = *type; +memcpy (&vtop->type, type, sizeof (CType)); that allow tcc to be compiled with a simpler C compiler, so that in time we could add to README something like - BOOTSTRAPPABLE! Because tcc uses only a subset of C99 (C99--), it can be bootstrapped with a simple C compiler. Knowing[1] that TinyCC can build Gcc (wow!) and building tcc is easier than building gcc, it is a good candidate for use in a bootstrap path. The past couple of months I have been working to bootstrap tcc using mescc, a simple C compiler that can (almost) be bootstrapped from source. I have just released[2] Mes 0.10 which can compile a modified version of mes-tcc, which can compile a trivial C program into a working executable. Much work will have to be done before mes-tcc will be able to build a functional Gcc. I would like to start by reducing the delta on tcc that I'm carrying. What do you think, is bootstrappable builds[4] something you would want to support and what could C99-- look like? Greetings, janneke [0] https://gitlab.com/janneke/tinycc/commits/wip-mescc [1] https://lists.gnu.org/archive/html/tinycc-devel/2017-05/msg00099.html [2] http://lists.gnu.org/archive/html/guile-user/2017-09/msg00027.html [3] http://bootstrappable.org -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
