Ok. Fine. Then let's look, how many lines it needs to write your own compiler. Means: Source language -> Windows .exe binary.
What do you think, how many lines are needed to generate 64-bit Machine code COFF executable format for Intel, AMD Ryzen, Thread Ripper, EPYC on Windows? I can tell you: 100 lines!!! https://github.com/d3dave/brainfuck-x64/blob/master/compile.py You are not "teaching" the right things, IMHO. Lisp -> x64 compiler is just a few lines longer, since you have to handle multiple stack machines. That's all! Compare to 2,5 million lines of LLVM code. Do you understand me now? Best regards, Guido Stepken Am Sonntag, 19. April 2020 schrieb Jo-To Schäg <johtob...@gmail.com>: > Dear Guido, > all our time on earth is limited. We all got our own priorities. > I think the PicoLisp community gladly spends time teaching people. Even multiple times. > However the PicoLisp community does not like to solve problems for other people. > Especially if it is motivated for political reasons. > Do not expect Alex to spend his time on satisfying your paranoia or political motivations. > You are weary of the giants of muscle and steel, I come from Cyberspace, the new home of Mind. On behalf of the future, I ask you of the past to leave us alone. You are not welcome among us. You political motivations have no sovereignty where we gather. - inspired by the Declaration of Cyberspace > Also you do not need to leave the community but at least stop bothering Alex about your political opinions. > We have heard you concern thrice. As far as i see we only use LLVM to translate LLVM-IR to some CPU architecture, so we only depend on the code for that. > You could write your own LLVM-IR to x86 translator if you are bothered by LLVM itself. > > > > On Sun, 19 Apr 2020 at 15:54, Guido Stepken <gstep...@gmail.com> wrote: >> >> Alex, this is not the point. One day LLVM will inject trojan code, because US government, by law, tells them to do so! >> >> With Cloud Act and Patriot Act US government can advise any US company or organisation to implement evil code. >> >> Can you do a full code review at every update coming for LLVM? I can't! Nobody can! 2.5 million lines is out of anybody's reach! >> >> 100 bytes more in a binary can make a *huge difference* from security oint of view. Do you always know, why LLVM suddenly is generating bigger code? Can be everything. E.g. this: >> >> https://gistgithub.com/DGivney/5917914 >> >> TCC, i can review any time .... code is so tiny. Well ok, TCC binary code is not as highly optimized in terms of speed, but AMD processor microcode does compensate that. Differences to GCC -O3 or LLVM - in practice - have become negligible. >> >> TCC always is fast enough. And i repeat: Stop using US software stacks! >> >> Best regards, Guido Stepken >> >> Am Sonntag, 19. April 2020 schrieb Alexander Burger <a...@software-lab.de >: >> > Hi Guido, >> > >> >> Look at LLVM generated bloat and compare with Nokolisp. Less is more!!! In >> >> terms of size as well as of security. >> > >> > True, LLVM is huge (as is gcc, and other equivalent systems), but this is >> > irrelevant because I *use* it only to translate *my* code. >> > >> > The generated pil21 'picolisp' binary is only a few percent larger than the >> > assembly version of pil64. >> > >> > ☺/ A!ex >> > >> > -- >> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> >
