Re: libc-mini.a should also include integer division algorithm

[Jan Nieuwenhuizen]

Danny Milosavljevic writes:

Hello!

> in mes on branch "wip-arm" some tests were failing because it didn't
> find the integer division function.  It turns out that libc-mini.a
> doesn't contain it--and some of the tests use libc-mini.a.  Some other
> tests don't use any libc--those are in an even worse situation.
>
> The patch at the bottom of this E-Mail would make all tests that use
> integer division but one work.
>
> However, I'm not sure that that's the better solution.

I agree...

> Choices we have:
>
> (1) To include div.c in crt1.c and thus have it always available--but
> right now that would mean that assertion failure and printing to the
> console have to be possible, too (they are used by div.c right now).
> (2) To make tests use libc-mini at least.
>
> I think that (1) is the less awful choice.  I think it should be fine
> to also just leave the division by zero handler in libc and fail if we
> don't have any such handler when linking.
>
> So we would split up lib/mes/div.c into two parts.  __mesabi_div0
> would go into libc and libc-mini; __mesabi_uldiv would go into crt1.
> ldiv I wonder about.  How do other compilers do it?

Good question.  I have looked at how we include (or not include) crt1 in
module/mescc/mescc.scm:

--8<---------------cut here---------------start------------->8---
         (start-files (if (or (option-ref options 'nostartfiles #f)
                              (option-ref options 'nostdlib #f)) '()
                              `("-f" ,(arch-find options "crt1.o"))))
--8<---------------cut here---------------end--------------->8---

and then remembered that in module/mescc.scm we have

--8<---------------cut here---------------start------------->8---
Ignored for GCC compatibility
  -fno-builtin
--8<---------------cut here---------------end--------------->8---

so...we coeuld put __mesabi_uldiv and __assert_fail into a new
"libc-builtin" and pass -fno-builtin to disable doing that.
WDYT?

> Also interesting to note is that the following is not allowed by gcc:
>
> struct foo {
> };
>
> int main() {
>         struct foo* x;
>         return (x + 1) - x;
> }
>
> y.c:7:17: error: arithmetic on pointer to an empty aggregate
>     7 |  return (x + 1) - x;

Oh...should we disallow that?  Does that make things easier?

> Note:
>
> Integer division is emitted by the our pointer subtractor.
>
> There, division by zero is impossible at runtime because it is caught
> before runtime.
>
> Pointer subtraction CAN give a negative result so our emitter is
> incorrect because right now it assumes that the divident and divisor
> are always positive.

Thta makes sense, thanks for clarifying that.  So, on x86 that's all
"handled" by the CPU, right?

> diff --git a/build-aux/configure-lib.sh b/build-aux/configure-lib.sh
> index ed0e23bb..9c03f29f 100644
> --- a/build-aux/configure-lib.sh
> +++ b/build-aux/configure-lib.sh
> @@ -32,6 +32,8 @@ fi
>  libc_mini_shared_SOURCES="
>  lib/mes/eputs.c
>  lib/mes/oputs.c
> +lib/mes/__assert_fail.c
> +lib/mes/div.c
>  "
>  
>  if test $mes_libc = mes; then

Great to have a working recipe already and let's see if we can do
better, like you proposed.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com