Re: Lightning Digest, Vol 114, Issue 4

[Paulo César Pereira de Andrade]

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
...
#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
> >