Ursprüngliche Nachricht
Von: gstep...@gmail.com
Gesendet: 6. Mai 2020 17:36
An: picolisp@software-lab.de
Antworten: picolisp@software-lab.de
Betreff: Re: Do free Open Source Foundation's Software Stacks fall under US
Export Law?
Am Mittwoch, 6. Mai 2020 schrieb Joh-Tob Schäg <johtob...@gmail.com>:
>Each one perhaps 50 pages long, that need to be adapted for supporting new CPU
>architecture.
Exactly.
>> Alex wrote he is tired of having to write meta assembler code for each
>> platform. I doubt that will be better if has to use someone else's Meta
>> assembler. Also LuaJIT does not target RISC-V.
> That's true so far. Though there a a couple of billion RISC-V cpus out there
> now.
And that's what matters to Alex.
> Target LLVM IR means porting it once and being able to target anything which
> has a translator.
>> And since when doesn't your C version of Picolisp compile on iOS?
>> Objective-C is a superset of C with parts of Smalltalk.
>
> You seem really ignorant. Are you unaware that pil32/emu/mini have less
> features than pil64 and are slower too due to overhead/resrictions used by C?
Is slower speed really an issue with pilbox GUI? Certainly not!
> Also the size of LLVM doesn't matter since it is only necessary when
> compiling the binary. You can likely download binaries Alex built just as you
> can do.
> "Compiling the binary" is funny .... pil21, sitting on top of LLVM JIT engine
> is post JIT'ing all the time during runtime. That thing is profiling and self
> optimizing code while running! See HotSpot JIT Engine concepts:
> https://en.wikipedia.org/wiki/HotSpot
BULLSHIT. Atleast as far as i can read the source:
https://github.com/picolisp/pil21/blob/master/src/lib/llvm.l
It is just dumping human readable LLVM-IR into a file which receives an ajead
of time compilation pass where it compiles the Picolisp language primitives for
the interpreter
> Starting interpreted, then stepwise compiling and replacing inner loops with
> machine code, outer loops, ... ? Starting slow, modern JIT engines are
> getting faster while running. Google V8 Javascript compiler is also working
> this way. That's why 'warm up' phase is often mentioned with benchmarks:
> https://www.google.com/search?q=llvm+warm+up+phase
You are plain wrong. LLVM can be used as AoT compiler too without anything
being a JIT. In fact the most common use case for LLVM is as an ahead-of-time
(AOT) compiler for a language.
> This is not different than Dynasm depending on LUA. Picolisp does not touch
> most LLVM code. It just needs the assembler part of it. Translating LLVM-IR
> to what ever you want is not that hard if you don't want to use LLVM and you
> can audit the resulting ASM.
> I am not reviewing or auditing 3 million lines of LLVM in my life. Apart from
> that, China market falls flat now because of US export sanctions.
Congrats than stay on the old pil64 or emu, audit the LLVM-IR assembler, write
your own LLVM-IR assembler.
Also stop the "China LLVM" talking point. Export control can't apply to code.
The PGP case showed that ages ago and even if it does, we Europeans don't have
to care about American export sanctions. As long as the code makes it to Europe
it can end in China.
> Wrong business strategy for Germany to use US toolchains any longer.
If you believe so.PԔ � &j)m����X��� ��zV�u�.n7�
