that transits Reax-664L binary to LNBM bit code targeting web assembly.
So first, I will explain what is web assembly or
wasn't for short and why we use wasn't.
And wasn't with a virtual machine instruction set and
currently this is used on servers or
as well as browsers in production environments.
And compared to existing applications,
there are mainly two features, portability and security.
And portability wasn't enabled us to run applications on both
browsers and servers without modification.
And of course, wasn't dependent on CPU architecture so
that we can run wasn't applications on computers with various
CPU architectures without modification.
And in security, in the case of outside browsers,
wasn't is highly isolated from the host kernel by Washi.
And Washi is an API that provides access to
similar OSR like features.
For example, for systems so gets and so on.
Yes, yes, and, yes, and
Washi is implemented by Washi at times.
For example, wasn't time and wasn't H and so on.
And was was was Harvard, Harvard architecture designs and
so the memory of the wasn't was wasn't instance is
which clearly separated into right now data memory and
memory and code of was can access only right now.
Data memory and which include increases security.
However, there are some limitations in the capability of
applications.
And first, wasn't can, wasn't can jump to only the course that
are determined at compare time and
in other words, it is impossible to indirectly jump to the code
generated in the data memory.
And second, was she implementation doesn't cover all
projects API, for example, folk and exec and so on.
So when you develop wasn't applications,
you should consider the limitations.
And now, many programming languages support was,
for example, C C plus plus plus and go and so on.
And however, it it isn't easy to build was in some cases as
follows.
And mainly there are three cases for us the programming
language that you want to use doesn't completely support
wasn't.
And, and currently many major languages have begun to
support wasn't, but only limited number of languages
are available in production environments now.
Second, binary is available, but source codes of the
binaries are not available.
And recently the number of op source, op source
programs has increased, but several, several programs are
still not published.
And third, the case of time consuming to building the
environment.
And if the dependent libraries of the target program are not
maintained, you might be not able to build the
libraries.
And in such a case, it might take much time to build.
So next, I show existing projects that run in X binary
on wasn't.
And the first, and the first project is tiny mu.
And this is the X86 and describe emulator available on
the browser.
And, and the next kernel can run on the browser.
And so, and the second project is counter to wasn't.
And this enables us to run the X kernel and counter,
run time with emulators compared to wasn't.
For example, tiny mu.
And, and, and this can, can run, well,
counter us without modification, but it can run
with the same amount of time.
And, and, and this can, can run, well, counter us
with modification both on the browsers and wash-around
times.
And, but, however, these projects, these, these
projects use PM on emulator that compiles a,
a, relax, describe 32 L binary to a,
a, several binary formats.
So next, I will show the demo of L, L comp.
Can you see? Watch.
Okay.
Okay. Thank you.
So, and, well, well, I have prepared the
counter image for the L comp project.
And, and, and now in, in this terminal, the container
of L comp has already started.
And the target sample L binary to be converted is
examples, L-sensitive, L-thousand.
And, and this program outputs 100, 100 prime
numbers in ascending order.
And, okay.
So we, we try to compare this L binary to was with L comp.
And in the directory, there's a one file L comp.sh
and L comp.sh is used to try to L comp to compile.
So, and, okay.
Okay. So, and target this was browser and L comp.
And target this was browser and L comp.
And target this L-sensitive L-thousand.
Now L comp comp.
Okay. Great.
And, and serial files are generated and we can
execute the was application with MS Gryffin.
So, run.
The browser.
Okay. So the cyber was the was application has
started now.
And, okay.
Wait.
You can see the, I'll put this correct in the browser.
Okay.
So, okay.
So now let's return to the presentation.
So, so, so in compiling L binary to L and B and B code
two, two modules are used.
Okay.
First is L comp lifter.
This process L binary and maps every section and
operates the next module.
And, and is a library for lifting machine code to L and B
and B code.
And, as this figure shows L comp comp,
L binary to L and B, L and B code with these two modules.
And next, I will explain how L comp comp,
L binary to L and B code and was binary.
And, and ramming converter function to one L,
B, M, I, R function.
For example, as you can see, the, the, the, the,
the, the square function one of the machine code is
combative to the underscore function one and the
square lift function is a L, M, B, M, I, R.
Yeah.
So, and also one CPU instruction is combative to one L,
B, M, I, R block.
And as you can see, the machine, the instruction of move X
to X zero of the machine code is combative to one underscore
move.
Yeah.
Okay.
Okay.
So next, I will explain the details of the combative,
combative L, B, M, I, R block from CPU instruction.
And there are three steps in the combative L, B, M, I, R block.
And the first step is the program counter calculation.
And this here shows percent 29 is a program counter of this
instruction.
And the next piece is updated to the next program counter.
Yeah.
And the second step is open calculation.
And in this here, this, this instruction uses X seven and
X three, X seven and X three registers.
And in the open calculation, the X seven and X three is
loaded.
Okay.
So, and the third step is calling the, calling the function
of the instruction-specific operation.
For each CPU instruction, RAMU generates a function that
performs the instruction-specific operation.
And the corresponding function is called at the end of the LM, I,
R block.
At this end.
So next, as I explained in the beginning, the code of the
quantum can indirectly jump to only the code that is
determinable at compare time.
And this figure shows how to deal with indirect jump VR
instruction.
So in this figure with VR X seven, indirectly jump to the
instruction of move X eight and X nine.
And in the error, the VR instruction.
And the address to jump is 30% IDR and jumps the block of
percent error on the square IDR.
This is the VR instruction.
Okay.
So, and after jumping, R on the square IDR, we get the target
rubber by calling the getR function and, and, and
start to pass the VR.
And after that, with the VR instruction, we jump to the
target block.
And also in that VR instruction, it requires all candidate
labels as the argument.
And this is, yeah, and this array consists of all labels in
this function.
And, well, but in the current design, the array of candidate
labels includes only the labels within this function.
So, and, and Elf Comp doesn't, doesn't support the jump and
long jump now.
And that is a future task.
And next in converting the LNB bit code to a wasn't
statically links the LNB bit code and Elf Comp runtime.
And Elf Comp runtime includes the mapped, mapped memory of the
original error binary.
And that is stuck in the heap area of the error binary.
So, and also Elf Comp runtime includes the program of the
system called the emulation.
And existing compiler, for example, M script and Washi CK
compiles these two modules to wasn't.
Okay.
So, and in the React system called emulation, there are two
ways of implementing the emulation.
And the way of implementing depends on the
RibBushy implementation.
And in case one, if the RibBushy implements the
tag system call, Elf Comp just uses the RibBushy function as
shown in this figure of the right system call.
Okay.
And in case two, if the RibBushy doesn't implements the
target, target system call, Elf Comp should implements the
system call.
And as shown in this figure of the not used PRK function in
this code.
So, it implements the system call.
Just watch out.
Okay.
So, next, I will show the parameters of the generated
binary, parameters evaluation.
Okay.
So, and the target sample F binary is a simple prime
number calculator.
And this program computes all prime numbers, lessens the
input to integer.
So, and one thing to notice here is that in this
program, the evaluation are using X H6 under square 64
binary instead of the wasn't binary.
Because in the current implementation, the system
call emulation for wash-down time is insufficient.
So, we use X H6 under square 64 as the output binary for
benchmark test.
I'm sorry.
So, and the comparison method is QM emulation X64 to X H6
and square 64.
So, we compare QM emulation with binary LD
compilation.
So, and I measure the power months in two cases.
In the first case, the input integer is 10 million.
And the second case is 15 million.
So, and the power month evaluation is as follows.
So, and as you can see, in both cases, one and the case two,
LD compiling by LFCOM is 4,000 QM emulation.
And therefore, we can say that LD compiling is 4,000 QM
emulation, at least in some cases.
So, okay, so last, I will show future works.
And first, we will support the output of other binary formats.
And currently, LFCOM supports the output binary of only
Wazm and LFX H664 binary now.
So, we will support the output of other binary as output of mine.
So, second, we will never as compiles LF binary
of other CPU architectures.
Now, LFCOM can compile H664 LF binary.
Yeah, so, yes.
In the future, we will support other input binary.
Okay, so, and third, we will, we will, we will
append system calls emulation.
And now LFCOM implements a part of system calls and
a lot of system calls are not implemented.
So, and specifically, when targeting Wazm as
the output binary formats, some system calls are
difficult to implement.
For example, for exec and so on.
Yeah, so, so, so, I think that
implementing that system calls is very variable.
So, and fourth, supporting dynamic linking.
And now LFCOM can compile the static,
static, link, LFU binary.
So, and that's where that dynamic linking is an
important function and will support in the future.
Yeah.
Okay, so, and fifth is the promise analysis of
the Wazm targets.
Yeah.
Now, I measure the promise evaluation under the
H664.
So, I shoot promise at the binary of the
Wazm targets.
Okay.
Okay, so, and the sixth is making LNB bit calls
generated more efficient.
Yeah, and, and so, yeah, okay.
So, in the current implemented.
I translate that to Wazm 32.
Sorry, well, I, sorry.
I, the 32 bit x86 platform.
So, I think that the H664 L binary is
mainly used in the world.
So, I think the support of the L binary H664 is
a big influence.
I think that's.
Yeah.
I take the top.
And you consider using it instead of
Remila revenge, if you know revenge.
I'm a core developer of revenge, disclaimer.
So, I'm sorry.
Could you, could you, if you have a question, more sorry.
Yeah.
Remila is a tool to leave from executable code to
bit code.
Yeah.
There's another tool which we developed, which is called
revenge that does something similar.
Maybe have you considered that?
Are you interested in that?
I don't know.
Sorry, I could use a more, sorry, sorry, sorry.
Yeah.
Is it an alternative to, revenge is an alternative
library to, Remila.
Have you, have you heard of that?
Well, have you heard of the revenge library?
Sorry.
It was just saying, if you'd heard of the revenge library,
does something similar to Remila.
It sounds like you haven't heard of it.
That was, that was my interpretation of the question.
I think that will fly.
I'm sorry.
Yeah.
When you measured, you did a performance between
Kwemu and Elfkong.
Yeah.
Was that like the, what did you measure there?
I didn't understand was it the compilation or running?
What did you measure in that performance?
Well, comparison performance.
Yes.
So, and, okay.
Yes.
Basically the, component performance is of Elfkong.
It's very long.
But in this project, in this program of the sample,
sample F binary, about, about it takes one minute
for the compiling.
Oh, yes.
It's the compilation that is faster.
Or is it the running of the thing that is faster?
Is it like, I don't, I don't understand.
We're measuring the, the running, like the produced results
for the compilation.
Like which?
Like which, I'm sorry.
And, I guess that is for like running.
That, yes.
So, by Kwemu, it runs, it runs like the, it has the,
the G that turns into the native code.
Like it has the, ahead of time, or you have ahead of time
compilation for that, what, what, what's that you run
on a browser, right?
Later.
So, are you looking at the performance running on the
browser here and comparing that to Kwemu?
Or are we looking at that, like some compilation item,
just understand like what are we comparing?
Sorry, so, could you ask after the presentation again?
Sorry.
I'm sorry.
Thank you.
Yeah.
So, you compare the performance with like emulated ARH 64
versus a X86 binary, binary.
Have you also tried, like after converting this with,
it was Alphcon to convert it back to ARH 64
and benchmark that against the original source?
So, like what is the overhead of one,
like lifting it and?
So, the question is overhead of the lifting,
binary lifting.
Oh, yeah.
So, yeah, so, and in the program of this
performance evaluation, the performance overhead of the
lifting is very small.
And maybe it takes maybe three or four seconds to
compare the lift, the binary to L and B bitcalls.
Yeah, but what I meant is like, if you combine the big bitcalls
back to the original architecture,
so how is the performance of that binary compared to the original binary?
So, you say that from L binary to the target architecture binary,
the performance overhead in the LB bitcalls to target binary.
Oh, sorry.
I just follow up on that.
So, if you just, I will just drop in directly,
but from experience.