[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lightning Digest, Vol 114, Issue 4
From: |
Marc Nieper-Wißkirchen |
Subject: |
Re: Lightning Digest, Vol 114, Issue 4 |
Date: |
Tue, 8 Nov 2022 07:48:03 +0100 |
Am Mo., 7. Nov. 2022 um 20:06 Uhr schrieb Paulo César Pereira de
Andrade <paulo.cesar.pereira.de.andrade@gmail.com>:
>
> Em seg., 7 de nov. de 2022 às 15:17, Marc Nieper-Wißkirchen
> <marc.nieper+gnu@gmail.com> escreveu:
> >
> > Am Mo., 7. Nov. 2022 um 18:43 Uhr schrieb Paulo César Pereira de
> > Andrade <paulo.cesar.pereira.de.andrade@gmail.com>:
> > >
> > > Em seg., 7 de nov. de 2022 às 11:50, Paulo César Pereira de Andrade
> > > <paulo.cesar.pereira.de.andrade@gmail.com> escreveu:
> > > >
> > > > Em dom., 6 de nov. de 2022 às 12:55, Francis McCabe
> > > > <frankmccabe@icloud.com> escreveu:
> > > >
> > > > > Hi Paulo
> > > >
> > > > Hi Francis,
> > > >
> > > > > So, your suggestion definitely allowed more progress.
> > > > >
> > > > > I now get:
> > > > >
> > > > > make CFLAGS="-D__OpenBSD__=1" check
> > > >
> > > > The commit
> > > > https://git.savannah.gnu.org/cgit/lightning.git/commit/?id=cf4e23aa06e07db3ce5a2debef7431add4b11674
> > > > makes it build and pass all tests.
> > > >
> > > > But note that some tests were disabled, because stack arguments
> > > > are packed and the caller must adjust the argument. It is the inverse
> > > > of what Windows and any Unix or Unix like system ABI does.
> > > >
> > > > It is advisable to only use jit_word_t and jit_float64_t data types.
> > > >
> > > > To be fully compliant, it would be required to add support for packed
> > > > stack, and a new family of pusharg calls, for example:
> > > >
> > > > jit_pushargr_c
> > > > jit_pushargr_uc
> > > >
> > > > etc
> > >
> > > I will wait a few more days before a new release, and once I
> > > have enough time I plan to implement (but no guarantees) the new:
> > >
> > > jit_code_pushargr_c, jit_code_pushargr_uc,
> > > jit_code_pushargr_s, jit_code_pushargr_us,
> > > jit_code_pushargr_i, jit_code_pushargr_ui
> > >
> > > that would be aliases to jit_pushargr and jit_pushargi
> > > on environments other than __APPLE__. Then, for __APPLE__
> > > would add extra code to make a packed stack based on the
> > > pusharg*_T and getarg*_T pairs. Basically only need to update
> > > offsets, as it already uses ldx*_T and stx*_T, just that it does
> > > not use a packed stack layout as all other ports do not need it.
> >
> > Does it mean that pushargr and pushargi will be deprecated?
>
> No. It would still work the same way.
>
> But need to add the new codes:
>
> jit_code_arg_c, jit_code_arg_uc,
> jit_code_arg_s, jit_code_arg_us,
> jit_code_arg_i, jit_code_arg_ui,
> jit_code_arg_l,
> jit_code_pushargr_c, jit_code_pushargi_c,
> jit_code_pushargr_uc, jit_code_pushargi_uc,
> jit_code_pushargr_s, jit_code_pushargi_s,
> jit_code_pushargr_us, jit_code_pushargi_us,
> jit_code_pushargr_i, jit_code_pushargi_i,
> jit_code_pushargr_ui, jit_code_pushargi_ui,
> jit_code_pushargr_l, jit_code_pushargi_l,
> jit_code_putargr_c, jit_code_putargi_c,
> jit_code_putargr_uc, jit_code_putargi_uc,
> jit_code_putargr_s, jit_code_putargi_s,
> jit_code_putargr_us, jit_code_putargi_us,
> jit_code_putargr_i, jit_code_putargi_i,
> jit_code_putargr_ui, jit_code_putargi_ui,
> jit_code_putargr_l, jit_code_putargi_l
>
> Basically would be in some pseudo code:
>
> #if __APPLE__
> #define jit_pushargr_c(c) _jit_pushargr_c(_jit, c)
> #else
> #define jit_pushargr_c(c) jit_pushargr(c)
> #endif
What I meant is that code using GNU lightning that wants to work even
on Apple hardware would have to check the uses of pushargr on a
case-by-case basis. Only when the argument is, in fact, a word, it is
safe to leave pushargr, right?
> ...
> #if __APPLE__
> jit_pushargr_c(Rc):
> if call_regarg < regarg_max:
> jit_extr_c(register(call_regarg_count), Rc);
> ++call_regarg;
> else: /* argument in stack */
> jit_stxi_c(call_stack_offset, JIT_FP, Rc);
> call_stack_offset += sizeof(char);
> jit_arg_c():
> int result;
> if self_regarg < regarg_max:
> result = self_regarg++;
> else /* income argument in stack */
> result = self_stack_offset;
> self_stack_offset += sizeof(char);
> return result;
> jit_getarg_c(Rc, offs):
> if (offs >= 0 && < regarg_max)
> jit_movr(Rc, regarg_base + offs);
> else
> jit_ldxi_c(Rc, JIT_FP, offs);
> #else
>
> /* The default, note that jit_pushargr_c would just alias to jit_pushargr */
>
> jit_pushargr(Rc):
> if call_regarg < regarg_max:
> jit_movr(regarg_base + call_regarg, Rc);
> ++call_regarg;
> else: /* argument in stack */
> jit_stxi_c(call_stack_offset, JIT_FP, Rc);
> call_stack_offset += sizeof(jit_word_t);
> jit_arg_c():
> int result;
> if self_regarg < regarg_max:
> result = self_regarg++;
> else /* income argument in stack */
> result = self_stack_offset;
> self_stack_offset += sizeof(jit_word_t);
> return result;
> jit_getarg_c(Rc, offs):
> if (offs >= 0 && < regarg_max)
> jit_extr_c(Rc, regarg_base + offs);
> else
> jit_ldxi_c(Rc, JIT_FP, offs);
> #endif
>
> Ais is now, there are only issues if calling functions with more
> than 8 arguments (actually 8 integers and 8 float/double). The first
> 8 arguments go on registers, but calling external code might require
> special care if calling code that receives non word size arguments;
> the caller must truncate and sign/zero extend.
>
> > > > This is required because it would not be required to have:
> > > >
> > > > jit_getarg_c and jit_getarg_uc
> > > >
> > > > because it is the caller that must zero or sign extend the argument.
> > > >
> > > > I am afraid lightning probably has been broken for 32 bit arm also
> > > > for significant time. But, for 32 bit, it should work if not using any
> > > > variadic function nor using types other than int, float and double.
> > > >
> > > > Due to a major issue with the 32 bit x86 compilation failure,
> > > > a new Lightning 2.1.5 release should be made soon. This will
> > > > include the patch listed above, to pass all tests in the sample
> > > > Apple M1.
> > > >
> > > > > …
> > > > >
> > > > > FAIL: 3to2
> > > > >
> > > > > ln -s ./check.sh add
> > > > >
> > > > > FAIL: add
> > > > >
> > > > > ln -s ./check.sh align
> > > > >
> > > > > FAIL: align
> > > > >
> > > > > ln -s ./check.sh allocai
> > > > >
> > > > > FAIL: allocai
> > > > >
> > > > > ln -s ./check.sh allocar
> > > > >
> > > > > FAIL: allocar
> > > > >
> > > > > ln -s ./check.sh bp
> > > > >
> > > > > FAIL: bp
> > > > >
> > > > > ln -s ./check.sh divi
> > > > >
> > > > > FAIL: divi
> > > > >
> > > > > ln -s ./check.sh fib
> > > > >
> > > > > FAIL: fib
> > > > >
> > > > > ln -s ./check.sh rpn
> > > > >
> > > > > FAIL: rpn
> > > > >
> > > > > ln -s ./check.sh ldstr
> > > > >
> > > > > PASS: ldstr
> > > > >
> > > > > ln -s ./check.sh ldsti
> > > > >
> > > > > PASS: ldsti
> > > > >
> > > > > ln -s ./check.sh ldstxr
> > > > >
> > > > > PASS: ldstxr
> > > > >
> > > > >
> > > > > …
> > > > >
> > > > > ============================================================================
> > > > >
> > > > > Testsuite summary for GNU lightning 2.1.4
> > > > >
> > > > > ============================================================================
> > > > >
> > > > > # TOTAL: 64
> > > > >
> > > > > # PASS: 46
> > > > >
> > > > > # SKIP: 0
> > > > >
> > > > > # XFAIL: 0
> > > > >
> > > > > # FAIL: 18
> > > > >
> > > > > # XPASS: 0
> > > > >
> > > > > # ERROR: 0
> > > > >
> > > > > ============================================================================
> > > > >
> > > > > See check/test-suite.log
> > > > >
> > > > > Please report to pcpa@gnu.org
> > > > >
> > > > > ============================================================================
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Looking forward to seeing more progress :)
> > > > >
> > > > > Francis
> > > > >
> > > > > On Nov 6, 2022, at 2:31 AM, Paulo César Pereira de Andrade
> > > > > <paulo.cesar.pereira.de.andrade@gmail.com> wrote:
> > > > >
> > > > > Em dom., 6 de nov. de 2022 às 02:30, Francis McCabe
> > > > > <frankmccabe@icloud.com> escreveu:
> > > > >
> > > > > Hi Francis,
> > > > >
> > > > > So, I am having a hard time with this stuff:
> > > > >
> > > > > I can’t use gdb, because it is not compiled for arm. I can use clang
> > > > > & lldb however.
> > > > > I can’t seem to find my way through the thicket of libtool and auto
> > > > > tool junk. In particular, I can’t figure out what is the actual
> > > > > executable that I can use to load into lldb.
> > > > >
> > > > >
> > > > > Sorry for this issue. My bad as I had access to this system
> > > > > https://cfarm.tetaneutral.net/news/41#
> > > > >
> > > > > When reading your email, I mostly guessed what could be wrong.
> > > > >
> > > > > I just tested in gcc104, and you can get it to mostly work if
> > > > > building as:
> > > > >
> > > > > $ ./configure --enable-assertions CFLAGS="-D__OpenBSD__=1"
> > > > > $ make CFLAGS="-D__OpenBSD__=1"
> > > > >
> > > > > Fixing the above is trivial.
> > > > > The major problem should be a different ABI for variadic functions.
> > > > >
> > > > > It should also be mostly trivial. It appears to use a very simple
> > > > > va_list as described at
> > > > > https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms
> > > > >
> > > > > Doing some initial work/research with a very simple example I get:
> > > > >
> > > > > gcc104:check pcpa$ lldb .libs/lightning
> > > > > ...
> > > > > (lldb) r add.tst
> > > > > error: process exited with status -1 (this is a non-interactive debug
> > > > > session, cannot get permission to debug processes.)
> > > > >
> > > > > apparently need some special procedures if running in a ssh
> > > > > connection.
> > > > >
> > > > > But hopefully it will not be required to be able to use a debugger
> > > > > as
> > > > > long as my guesses are right :), and fixing the lldb issue probably
> > > > > needs sudo privilege.
> > > > >
> > > > > I believe I will not be able to work on it early today. But hopefully
> > > > > by tomorrow I will have a patch.
> > > > >
> > > > > Sorry for not having properly tested it for the Lightning 2.1.4
> > > > > release.
> > > > >
> > > > >
> > > > > On Nov 5, 2022, at 9:00 AM, lightning-request@gnu.org wrote:
> > > > >
> > > > > Send Lightning mailing list submissions to
> > > > > lightning@gnu.org
> > > > >
> > > > > To subscribe or unsubscribe via the World Wide Web, visit
> > > > > https://lists.gnu.org/mailman/listinfo/lightning
> > > > > or, via email, send a message with subject or body 'help' to
> > > > > lightning-request@gnu.org
> > > > >
> > > > > You can reach the person managing the list at
> > > > > lightning-owner@gnu.org
> > > > >
> > > > > When replying, please edit your Subject line so it is more specific
> > > > > than "Re: Contents of Lightning digest..."
> > > > >
> > > > >
> > > > > Today's Topics:
> > > > >
> > > > > 1. Re: Lightning Digest, Vol 114, Issue 2 (Marc Nieper-Wißkirchen)
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------------
> > > > >
> > > > > Message: 1
> > > > > Date: Sat, 5 Nov 2022 16:58:21 +0100
> > > > > From: Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com>
> > > > > To: Francis McCabe <frankmccabe@icloud.com>
> > > > > Cc: Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com>,
> > > > > lightning@gnu.org
> > > > > Subject: Re: Lightning Digest, Vol 114, Issue 2
> > > > > Message-ID:
> > > > >
> > > > > <CAEYrNrTfrHDazMtifwCdgH5aS0mnBS+Lms5pXKs9Nra8HBh2Rw@mail.gmail.com>
> > > > > Content-Type: text/plain; charset="UTF-8"
> > > > >
> > > > > Am Sa., 5. Nov. 2022 um 15:54 Uhr schrieb Francis McCabe
> > > > > <frankmccabe@icloud.com>:
> > > > >
> > > > >
> > > > > It hangs on that 3ro2 test. If I control-c then it cleans up that log
> > > > > file
> > > > >
> > > > >
> > > > > Can you run it with gdb?
> > > > >
> > > > >
> > > > > Sent from my iPhone
> > > > >
> > > > > On Nov 5, 2022, at 6:24 AM, Marc Nieper-Wißkirchen
> > > > > <marc.nieper+gnu@gmail.com> wrote:
> > > > >
> > > > > Am Sa., 5. Nov. 2022 um 06:59 Uhr schrieb Francis McCabe
> > > > > <frankmccabe@icloud.com>:
> > > > >
> > > > >
> > > > > I tried downloading and building lightning-2.1.4
> > > > >
> > > > > On my mac M1
> > > > >
> > > > > make check hangs on 3to2
> > > > >
> > > > > Is this ever going to get fixed?
> > > > >
> > > > >
> > > > > Can you be a bit more precise about what actually happens? Or does
> > > > > the process crash without any output?
> > > > >
> > > > >
> > > > > Francis
> > > > > P.S. If not, then I will not bother y’all again.
> > > > >
> > > > > On Nov 4, 2022, at 9:00 AM, lightning-request@gnu.org wrote:
> > > > >
> > > > >
> > > > > Send Lightning mailing list submissions to
> > > > > lightning@gnu.org
> > > > >
> > > > > To subscribe or unsubscribe via the World Wide Web, visit
> > > > > https://lists.gnu.org/mailman/listinfo/lightning
> > > > > or, via email, send a message with subject or body 'help' to
> > > > > lightning-request@gnu.org
> > > > >
> > > > > You can reach the person managing the list at
> > > > > lightning-owner@gnu.org
> > > > >
> > > > > When replying, please edit your Subject line so it is more specific
> > > > > than "Re: Contents of Lightning digest..."
> > > > >
> > > > >
> > > > > Today's Topics:
> > > > >
> > > > > 1. GNU lightning 2.1.4 release (Paulo César Pereira de Andrade)
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------------
> > > > >
> > > > > Message: 1
> > > > > Date: Fri, 4 Nov 2022 09:54:01 -0300
> > > > > From: Paulo César Pereira de Andrade
> > > > > <paulo.cesar.pereira.de.andrade@gmail.com>
> > > > > To: lightning <lightning@gnu.org>
> > > > > Subject: GNU lightning 2.1.4 release
> > > > > Message-ID:
> > > > >
> > > > > <CAHAq8pGNRjSo_hoUyduATCc6GRQs4utGJkA5h4Qxa4cOvrDwaQ@mail.gmail.com>
> > > > > Content-Type: text/plain; charset="UTF-8"
> > > > >
> > > > > GNU lightning 2.1.4 released!
> > > > >
> > > > > GNU lightning is a library to aid in making portable programs
> > > > > that compile assembly code at run time.
> > > > >
> > > > > Development:
> > > > > http://git.savannah.gnu.org/cgit/lightning.git
> > > > >
> > > > > Download release:
> > > > > ftp://ftp.gnu.org/gnu/lightning/lightning-2.1.4.tar.gz
> > > > >
> > > > > 2.1.4 main features are the new Loongarch port, currently supporting
> > > > > only Linux 64 bit, and a new rewrite of the register live and
> > > > > unknown state logic. Now it should be faster to generate code.
> > > > >
> > > > > The matrix of built and tested environments is:
> > > > > aarch64 Linux
> > > > > alpha Linux (QEMU)
> > > > > armv7l Linux (QEMU)
> > > > > armv7hl Linux (QEMU)
> > > > > hppa Linux (32 bit, QEMU)
> > > > > i686 Linux, FreeBSD, NetBSD, OpenBSD and Cygwin/MingW
> > > > > ia64 Linux
> > > > > mips Linux
> > > > > powerpc32 AIX
> > > > > powerpc64 AIX
> > > > > powerpc64le Linux
> > > > > riscv Linux
> > > > > s390 Linux
> > > > > s390x Linux
> > > > > sparc Linux
> > > > > sparc64 Linux
> > > > > x32 Linux
> > > > > x86_64 Linux and Cygwin/MingW
> > > > >
> > > > > ------------------------------------------------------------------------
> > > > >
> > > > > Highlights are:
> > > > >
> > > > > o Faster jit generation.
> > > > > o New loongarch port.
> > > > > o New skip instruction and rework of the align instruction.
> > > > > o New bswapr_us, bswapr_ui, bswapr_ul byte swap instructions.
> > > > > o New movzr and movnr conditional move instructions.
> > > > > o New casr and casi atomic compare and swap instructions.
> > > > > o Use short unconditional jumps and calls to forward, not yet defined
> > > > > labels.
> > > > > o And several bug fixes and optimizations.
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------
> > > > >
> > > > > Subject: Digest Footer
> > > > >
> > > > > _______________________________________________
> > > > > Lightning mailing list
> > > > > Lightning@gnu.org
> > > > > https://lists.gnu.org/mailman/listinfo/lightning
> > > > >
> > > > >
> > > > > ------------------------------
> > > > >
> > > > > End of Lightning Digest, Vol 114, Issue 2
> > > > > *****************************************
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------
> > > > >
> > > > > Subject: Digest Footer
> > > > >
> > > > > _______________________________________________
> > > > > Lightning mailing list
> > > > > Lightning@gnu.org
> > > > > https://lists.gnu.org/mailman/listinfo/lightning
> > > > >
> > > > >
> > > > > ------------------------------
> > > > >
> > > > > End of Lightning Digest, Vol 114, Issue 4
> > > > > *****************************************
> > > > >
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Paulo
> > > >
> > > > Thanks!
> > > > Paulo
> > >
- Re: Lightning Digest, Vol 114, Issue 4, Francis McCabe, 2022/11/06
- Re: Lightning Digest, Vol 114, Issue 4, Marc Nieper-Wißkirchen, 2022/11/06
- Re: Lightning Digest, Vol 114, Issue 4, Paulo César Pereira de Andrade, 2022/11/06
- Re: Lightning Digest, Vol 114, Issue 4, Francis McCabe, 2022/11/06
- Re: Lightning Digest, Vol 114, Issue 4, Paulo César Pereira de Andrade, 2022/11/07
- Re: Lightning Digest, Vol 114, Issue 4, Paulo César Pereira de Andrade, 2022/11/07
- Re: Lightning Digest, Vol 114, Issue 4, Marc Nieper-Wißkirchen, 2022/11/07
- Re: Lightning Digest, Vol 114, Issue 4, Paulo César Pereira de Andrade, 2022/11/07
- Re: Lightning Digest, Vol 114, Issue 4,
Marc Nieper-Wißkirchen <=
- Re: Lightning Digest, Vol 114, Issue 4, Paulo César Pereira de Andrade, 2022/11/08