06:45 <tankf33der> o/

06:46 <Regenaxer> Good morning tankf33der!

07:50 <Nistur> mornin'

07:53 <mtsd> Good morning!

07:53 <Nistur> not so sure about the 'good' bit yet, but sure ;)

07:53 <Regenaxer> Hi Nistur, mtsd!

07:54 <Nistur> hullo :)

07:55 <Regenaxer> I'm struggling with LLVM. Not sure if it is good yet, the VM is more restricted than curren PilVM

07:55 <mtsd> Hello Regenaxer!

07:55 <Regenaxer> :)

07:55 <mtsd> I was about to ask you how the llvm investigations were going

07:56 <Regenaxer> I still see no solution for 'native'. Otherwise it is going well so far

07:56 <mtsd> Ok

07:56 <Regenaxer> The promise is that LLVM is a lot more portable

07:57 <Regenaxer> i.e. easier to port

07:58 <Regenaxer> I can't find info in the LLVM docs whether completely dynamic function calls are possible, as needed for 'native'

07:58 <Regenaxer> Also, carry flag is missing, so bignums are more tedious

07:59 <Nistur> I did have a look at using LLVM as the backend for an experiment I was looking, and it just looked so... large and unweildy

07:59 <Regenaxer> True

07:59 <Regenaxer> The intermediate lang is horrible!

07:59 <Regenaxer> But I see it has its advantages

07:59 <Nistur> I decided I didn't have enough time to put into it, but I also came across a similar, much smaller project, which seemed like it solved _most_ of my requirements

08:00 <Regenaxer> ok

08:00 <Nistur> QBE or BQE or some combination of those letters

08:00 <Regenaxer> I think I solved all issues with that lang though

08:00 <Nistur> https://c9x.me/compile/ QBE

08:01 <Regenaxer> I don't focus on backend. Implemented a frontend

08:01 <Regenaxer> the backend for all target archs is there

08:01 <Regenaxer> and it is good

08:02 <Regenaxer> very optimized in LLVM

08:02 <Nistur> yup

08:03 <Regenaxer> My frontend for pil is very simple. Less than 1000 lines

08:03 <Regenaxer> (written in pil of course, no C++ needed)

08:05 <mtsd> Sounds promising

08:05 <Regenaxer> Yeah, except for 'native'

08:05 <Regenaxer> Not sure if solvable

08:06 <Nistur> the reason I was leaning towards QBE over LLVM is that, as with most of my projects, I knew that if I Started it, I wouldn't have much time, so I wanted a much smaller problem to deal with, and learning LLVM nuances. In the end I didn't have time for either :P But if I was doing something for production (as you would be with Pil of course) then LLVM would be a more sensible option yep :P

08:06 <Regenaxer> LLVM is sooo static

08:06 <Regenaxer> and strongly typed which is a headache for pil

08:06 <Regenaxer> Nistur, yes, you mentioned QBE last time

08:07 <Regenaxer> But the reason for me for LLVM is portability. Only!

08:08 <Regenaxer> QBE is not of help in MacOS or iOS and oher platforms

08:08 <Regenaxer> The trigger for me was RISC-V

08:08 <Nistur> I did? I don't think so :P I thought I found it relatively recently (although I may have re-found it to be honest... I keep finding projects that I think would be a good idea, only to find that I started them a couple of years back)

08:08 <Regenaxer> RISC-V has no CPU flags, so porting PilVM is a hassle

08:08 <Regenaxer> Yes, short time ago

08:09 <Nistur> Hmmm, nothing in my logs for QBE prior to today... :S

08:10 <mtsd> Someone mentioned QBE a while ago, I don't remember who it was though

08:10 <Regenaxer> Not sure, I looked at a link some time ago, about an alternative to LLVM

08:11 <Regenaxer> And thought it won't help me

08:11 <mtsd> Checked my logs, it was tankf33der :)

08:12 <Regenaxer> ah!

08:12 <tankf33der> https://git.sr.ht/%7Emcf/cproc

08:13 <tankf33der> this c implementation have qbe on backend and it can compile and pass tests on Monocypher

08:13 <tankf33der> speed is like raw gcc.

08:13 <Regenaxer> thanks tankf33der

08:13 <tankf33der> also myrlang has qbe as backend.

08:14 <Regenaxer> Would it help to bring pilVM to RISC-V, Mac or iOS?

08:14 <Regenaxer> and other future platforms?

08:15 <Regenaxer> And: Would it support 'native' better?

08:15 <Regenaxer> The problem with all such systems is that they are intended for static compilation

08:16 <Regenaxer> Much less flexible as pure Asm in pil

08:17 <Regenaxer> A little more powerful than C though, so 2tter than pil32

08:17 <tankf33der> Regenaxer: you will not find. pilvm is uniq.

08:17 <Regenaxer> probably

08:18 <tankf33der> probably? they dont exist :)

08:19 <Regenaxer> Who knows

08:19 <Regenaxer> For now, let's explore LLVM

08:19 <Regenaxer> perhaps a good compromise

08:20 <Regenaxer> One nice thing on my new inplementation is that the implementation lang of the kernel is now a subset of Pil (instead C or Asm or Java)

08:22 <tankf33der> just port pilvm to risc-v in 5-10 days.

08:22 <Regenaxer> Yes, this would be faster

08:22 <tankf33der> come on :)

08:22 <Regenaxer> but not efficient

08:23 <Regenaxer> RISC-V has no condition codes

08:23 <Regenaxer> and PilVM completely depends on them

08:23 <tankf33der> so llvm also.

08:23 <Regenaxer> yes, so I write another VM

08:24 <Regenaxer> but LLVM has at least overflow (though no carry)

08:24 <Regenaxer> In total it is like a C more low level

08:31 <Regenaxer> I write a skeleton now, only so much that the 'fibo' benchmark works. No bignums or DB.

08:31 <Regenaxer> Absolute minimum

08:33 <tankf33der> good.

08:49 <tankf33der> lets try test pil on linux kernel 5.3.1

08:49 <Regenaxer> OK

08:49 <Regenaxer> You think something in system calls changed?

08:50 <tankf33der> 5.2 was ok

08:50 <tankf33der> 5.2.x was ok

08:50 <tankf33der> 5.3 also passed.

08:50 <Regenaxer> Great