lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU lightning 2.2.0 released!


From: Paulo César Pereira de Andrade
Subject: Re: GNU lightning 2.2.0 released!
Date: Wed, 16 Nov 2022 20:50:07 -0300

Em qua., 16 de nov. de 2022 às 17:42, Basile Starynkevitch
<basile@starynkevitch.net> escreveu:

  Hi,

> On 16/11/2022 16:17, Paulo César Pereira de Andrade wrote:
> > GNU lightning 2.2.0 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.2.0.tar.gz
> >
> >    GNU Lightning 2.2.0 extends the 2.1.4 release adding support for
> > Darwin aarch64, tested on Apple M1.
> >
> >    Now there is the new --enable-devel-strong-type-checking configure
> > option, not enabled by default, but code that works with that option
> > will work on Apple M1.
> >
> >    This release required significant rework as the Apple abi in aarch64
> > requires arguments to be truncated and zero/sign extended, unlike all
> > other ports. Jit generation will understand it, and use the system ABI,
> > avoiding double truncate and zero/sign extension.
> >
> >    Due to the significant rework, the library major number was bumped,
> > and the opportunity used to reorder the jit_code_t enumeration.
>
>
>
> FWIW, I am considering using GNU lightning in the RefPerSys open source
> project on http://refpersys.org/

  It is very good to know about the usage of GNU Lightning. If you have
any problems or questions, please feel free to ask.

> However,  lightning-2.2.0 get warning when configured on Ubuntu 22.10
> with AMD Ryzen Threadripper 2970WX as:
>
> ./configure CFLAGS='-O2 -g'  --enable-disassembler
> --enable-devel-disassembler --enable-devel-get-jit-size

  The --enable-devel-get-jit-size is not really required, as the distribution
already provides the jit_${ARCH}-sz.c files required to estimate the
size of the generated code. It also only makes sense if running:

$ make get_jit_size

that will run 'make check' and create the jit_${ARCH}-sz.c file
based on gathered data. Unless working on how lightning instructions
are translated to machine code, this option should not be used, or
it will create a file logging the size of all generated instructions.

  If you are starting using lightning, I suggest using the --enable-assertions
during development, as otherwise it might be too difficult to debug any
problems. Once you know it is working correctly, you can use a runtime
without assertions enabled.

> rimski.x86_64 src/Libs/lightning-2.2.0 21:41 .0 % make
> make  all-recursive
> make[1]: Entering directory '/usr/src/Libs/lightning-2.2.0'
> Making all in gnulib-lib
> make[2]: Entering directory '/usr/src/Libs/lightning-2.2.0/gnulib-lib'
> make  all-recursive
> make[3]: Entering directory '/usr/src/Libs/lightning-2.2.0/gnulib-lib'
> make[4]: Entering directory '/usr/src/Libs/lightning-2.2.0/gnulib-lib'
>    CC       dummy.lo
>    CCLD     libgnu.la
> make[4]: Leaving directory '/usr/src/Libs/lightning-2.2.0/gnulib-lib'
> make[3]: Leaving directory '/usr/src/Libs/lightning-2.2.0/gnulib-lib'
> make[2]: Leaving directory '/usr/src/Libs/lightning-2.2.0/gnulib-lib'
> Making all in check
> make[2]: Entering directory '/usr/src/Libs/lightning-2.2.0/check'
> make[2]: Nothing to be done for 'all'.
> make[2]: Leaving directory '/usr/src/Libs/lightning-2.2.0/check'
> Making all in doc
> make[2]: Entering directory '/usr/src/Libs/lightning-2.2.0/doc'
>    CC       incr.o
> cd ../lib; make  liblightning.la
> make[3]: Entering directory '/usr/src/Libs/lightning-2.2.0/lib'
>    CC       jit_disasm.lo
> jit_disasm.c: In function ‘disasm_print_address’:
> jit_disasm.c:249:41: warning: format ‘%lx’ expects argument of type
> ‘long unsigned int’, but argument 3 has type ‘long long int’ [-Wformat=]
>    249 | #  define address_buffer_format         "%lx"
>        |                                         ^~~~~
> jit_disasm.c:259:21: note: in expansion of macro ‘address_buffer_format’
>    259 |     sprintf(buffer, address_buffer_format, (long long)addr);
>        |                     ^~~~~~~~~~~~~~~~~~~~~
> jit_disasm.c:249:44: note: format string is defined here
>    249 | #  define address_buffer_format         "%lx"
>        |                                          ~~^
>        |                                            |
>        |                                            long unsigned int
>        |                                          %llx
> jit_disasm.c: In function ‘_disassemble’:
> jit_disasm.c:249:41: warning: format ‘%lx’ expects argument of type
> ‘long unsigned int’, but argument 3 has type ‘long long int’ [-Wformat=]
>    249 | #  define address_buffer_format         "%lx"
>        |                                         ^~~~~
> jit_disasm.c:409:33: note: in expansion of macro ‘address_buffer_format’
>    409 |         bytes = sprintf(buffer, address_buffer_format, (long
> long)pc);
>        |                                 ^~~~~~~~~~~~~~~~~~~~~
> jit_disasm.c:249:44: note: format string is defined here
>    249 | #  define address_buffer_format         "%lx"
>        |                                          ~~^
>        |                                            |
>        |                                            long unsigned int
>        |                                          %llx

  Thanks. This should be harmless, but should be fixed to avoid the
warnings. The (long long) cast is useful to work the same way in 32
or 64 bits. It really should be using a cast to (bfd_vma) to avoid needing
to do casts based on wordsize.

>    CC       jit_memory.lo
>    CC       jit_names.lo
>    CC       jit_note.lo
>    CC       jit_print.lo
>    CC       jit_size.lo
> jit_size.c: In function ‘jit_finish_size’:
> jit_size.c:160:23: warning: format ‘%d’ expects argument of type ‘int’,
> but argument 3 has type ‘jit_word_t’ {aka ‘long int’} [-Wformat=]
>    160 |         fprintf(fp, "%d %d\n", offset, _szs[offset]);
>        |                      ~^        ~~~~~~
>        |                       |        |
>        |                       int      jit_word_t {aka long int}
>        |                      %ld

  This should also be trivial to fix, just replace the type of the
offset variable
with a 32 bit integer.

>    CC       lightning.lo
>    CCLD     liblightning.la
> make[3]: Leaving directory '/usr/src/Libs/lightning-2.2.0/lib'
>    CCLD     incr
>    CC       printf.o
>    CCLD     printf
>    CC       rpn.o
>    CCLD     rpn
>    CC       rfib.o
>    CCLD     rfib
>    CC       ifib.o
>    CCLD     ifib
>    CC       fact.o
>    CCLD     fact
> make[2]: Leaving directory '/usr/src/Libs/lightning-2.2.0/doc'
> Making all in include
> make[2]: Entering directory '/usr/src/Libs/lightning-2.2.0/include'
> Making all in lightning
> make[3]: Entering directory
> '/usr/src/Libs/lightning-2.2.0/include/lightning'
> make[3]: Nothing to be done for 'all'.
> make[3]: Leaving directory '/usr/src/Libs/lightning-2.2.0/include/lightning'
> make[3]: Entering directory '/usr/src/Libs/lightning-2.2.0/include'
> make[3]: Nothing to be done for 'all-am'.
> make[3]: Leaving directory '/usr/src/Libs/lightning-2.2.0/include'
> make[2]: Leaving directory '/usr/src/Libs/lightning-2.2.0/include'
> Making all in lib
> make[2]: Entering directory '/usr/src/Libs/lightning-2.2.0/lib'
> make[2]: Nothing to be done for 'all'.
> make[2]: Leaving directory '/usr/src/Libs/lightning-2.2.0/lib'
> make[2]: Entering directory '/usr/src/Libs/lightning-2.2.0'
>    CC       size.o
>    CCLD     size
> make[2]: Leaving directory '/usr/src/Libs/lightning-2.2.0'
> make[1]: Leaving directory '/usr/src/Libs/lightning-2.2.0'
>
>
> These warnings are reproducible after a make clean
>
>
> Thanks for reading
>
> --
> Basile Starynkevitch                  <basile@starynkevitch.net>
> (only mine opinions / les opinions sont miennes uniquement)
> 92340 Bourg-la-Reine, France
> web page: starynkevitch.net/Basile/

Thanks!
Paulo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]