Hello Virgil (and all),
As part of my research I have been working on a RISC-V port of DuskOS
and recently "finished" it.
RISC-V platforms might not be in your scope of targeted platforms, but
it was a very interesting exercise to oppose RISC-V ISA to DuskOS kernel
specifications due to RISC-V differences with ARM and i386.
Still, if you are interested in getting the port code, I can send it to
you. I have been working on Dusk v4 for this, so it will need a patch to
be updated to v11, but if you are interested, I can work it.
Also, do you have an idea about the amount of work needed to do this
patch from v4 to v11 ?
A summary of what is currently available on this port :
- it is currently only running on the RISC-V QEMU "virt" emulation
> I have heard about Raspberry low-cost board making use of RISC-V
cores, it might be an interesting platform for a physical port
- it has a very simple UART driver allowing it to be interactive
- currently the filesystem is loaded in an allocated memory region and
is interacted with using a slightly modified "ramdrive" driver
- it does compile "tests/all.fs" and passes all the tests
- and also I have been able to cross-compile a working
RaspberryPi DuskOS image from a RISC-V DuskOS instance
Don't hesitate if you have any questions !
Lucas.
On Mon, Oct 07, 2024 at 03:07:54PM +0200, Lucas Chaloyard wrote:
> Hello Virgil (and all),> > As part of my research I have been working on a RISC-V port of DuskOS and> recently "finished" it.> > RISC-V platforms might not be in your scope of targeted platforms, but it> was a very interesting exercise to oppose RISC-V ISA to DuskOS kernel> specifications due to RISC-V differences with ARM and i386.> > Still, if you are interested in getting the port code, I can send it to you.> I have been working on Dusk v4 for this, so it will need a patch to be> updated to v11, but if you are interested, I can work it.> Also, do you have an idea about the amount of work needed to do this patch> from v4 to v11 ?> > A summary of what is currently available on this port :> - it is currently only running on the RISC-V QEMU "virt" emulation> > I have heard about Raspberry low-cost board making use of RISC-V> cores, it might be an interesting platform for a physical port> - it has a very simple UART driver allowing it to be interactive> - currently the filesystem is loaded in an allocated memory region and> is interacted with using a slightly modified "ramdrive" driver> - it does compile "tests/all.fs" and passes all the tests> - and also I have been able to cross-compile a working> RaspberryPi DuskOS image from a RISC-V DuskOS instance> > Don't hesitate if you have any questions !> > Lucas.
Hello Lucas,
Not in my scope?! It's Christmas in October! This is awesome news! Of course
I'm interested. I will also be glad to assist in any way I can to upgrade it
to v11.
To have an idea of the work involved, you can look at the git log for
xcomp/arm/kernel.fs. The work needed on the RISC-V kernel should be similar.
If anything, the kernel has gotten slimmer since then. v9 is the biggest chunk,
with the introduction of a layer of indirection for HERE and changes in
branching semantics. But all in all, the amount of work involved should be minor
compared to what you've done so far.
Still, I recommend going one version at a time. There hasn't been much back and
forth, so you won't lose much time going incrementally, but you might save some
debugging time.
Regards,
Virgil
Thanks for the quick answer and I'm glad to see that you find value in
this work!
Also, thanks for the info and tips, I'll take a look at the git logs
like you said.
Going one version at a time seems a good idea, I might not spend as much
time a week as I was when doing the port, so going one version at a time
might be perfect to organize myself.
I'll let you know how it goes and if I encounter any issue.
Lucas.
On Mon, Oct 07, 2024 at 03:42:12PM +0200, Lucas Chaloyard wrote:
> Thanks for the quick answer and I'm glad to see that you find value in this> work!> > Also, thanks for the info and tips, I'll take a look at the git logs like> you said.> Going one version at a time seems a good idea, I might not spend as much> time a week as I was when doing the port, so going one version at a time> might be perfect to organize myself.> > I'll let you know how it goes and if I encounter any issue.> > Lucas.
Hello again Lucas,
I hope you are having fun with the RISC-V port. I realize that I might have been
unclear in my communications: I'm eager to see that port :)
I don't want to rob you of any fun you might have upgrading the port to the
latest Dusk, so if you prefer to upgrade it all by yourself, by all means, don't
let my eagerness disturb you.
But if that process is less fun than it should, or if you have difficulties
finding time to do it, you should know that I will gladly do that work.
Moreover, the refactoring I've just finished doing on all kernels represents
a major work: the HAL is now implemented in Forth rather than assembly. It will
make future ports easier to write, but it represents a significant effort to
translate an existing kernel. I really don't mind if you want to leave that
part to me.
Regards,
Virgil
Hi Virgil,
Sorry for the delayed answer.
To be honest I think I will have a hard time finding times to upgrade it
in the moment.
I did upgraded to v5, not entirely, the kernel is rewritten and it seems
to be working, but there is still work to be done for I/O, which I had
working with a simple UART driver, but I think it is not enough for the
v5.
So, if you want to work on the upgrade, I'll gladly give you the current
state of the port, and I'll be happy to watch and help you while you
work on it.
How do you want me to send you the port ? Patches ?
Lucas.
On Tue, Nov 12, 2024 at 10:30:23AM +0100, Lucas Chaloyard wrote:
> Hi Virgil,> > Sorry for the delayed answer.> > To be honest I think I will have a hard time finding times to upgrade it in> the moment.> I did upgraded to v5, not entirely, the kernel is rewritten and it seems to> be working, but there is still work to be done for I/O, which I had working> with a simple UART driver, but I think it is not enough for the v5.> > So, if you want to work on the upgrade, I'll gladly give you the current> state of the port, and I'll be happy to watch and help you while you work on> it.> > How do you want me to send you the port ? Patches ?> > Lucas.
Hello Lucas,
Great, I'll be glad to take care of it.
I'd suggest two patches. First, a patch of the working port against v4. Then,
a patch of the partially working port against v5.
On my side, I'll create a "riscv" branch in the Dusk OS repo and integrate your
work in there, then continue my upgrade work there. When I catch up with master,
I merge it all.
Sounds good to you?
Regards,
Virgil
Hello Virgil,
Sounds great to me ! Can't wait to see you work on it.
If you have any questions regarding anything, you can ask me, I'll try
to answer quickly.
There is 3 patches :
> riscv-v4.patch => Add the RISC-V port to a DuskOS repo on v4 tag
> riscv-v4-deploymennts.patch => Add the RISC-V port deployment to a
duskos-deployments repo on commit 78d8d0de3b490b87ec95180e4d15a87fbbebb125
> riscv-v4tov5.patch => It should patch correctly on a DuskOS repo with
RISC-V port added on v4 and then rebased to v5
I've tested them on a cleaned version of your repos, so it should be
easy to patch.
A few things to know :
1. I added signed comparison operators to the boot.fs, because I used
them in the RISC-V assembler.
2. 1-byte jump/branch instructions in RISC-V can go over 1 MB, so when
porting the kernel I decided to mainly used a 2-byte sequence of
instructions allowing to jump further, but now I'm not sure it was truly
necessary.
3. RISC-V instruction set encoding is quite different from ARM (and i386
I guess), so our assemblers might be quite different too, but you can
ask me anything about it.
And if you see any possible upgrades of fixes to be done on the code I
wrote, go for it, I don't mind at all !
Thank you !
Lucas.
On Wed, Nov 13, 2024 at 11:13:46AM +0100, Lucas Chaloyard wrote:
> Hello Virgil,> > Sounds great to me ! Can't wait to see you work on it.> If you have any questions regarding anything, you can ask me, I'll try to> answer quickly.> > There is 3 patches :> > riscv-v4.patch => Add the RISC-V port to a DuskOS repo on v4 tag> > riscv-v4-deploymennts.patch => Add the RISC-V port deployment to a> duskos-deployments repo on commit 78d8d0de3b490b87ec95180e4d15a87fbbebb125> > > riscv-v4tov5.patch => It should patch correctly on a DuskOS repo with> RISC-V port added on v4 and then rebased to v5> > I've tested them on a cleaned version of your repos, so it should be easy to> patch.> > A few things to know :> 1. I added signed comparison operators to the boot.fs, because I used them> in the RISC-V assembler.> 2. 1-byte jump/branch instructions in RISC-V can go over 1 MB, so when> porting the kernel I decided to mainly used a 2-byte sequence of> instructions allowing to jump further, but now I'm not sure it was truly> necessary.> 3. RISC-V instruction set encoding is quite different from ARM (and i386 I> guess), so our assemblers might be quite different too, but you can ask me> anything about it.> > And if you see any possible upgrades of fixes to be done on the code I> wrote, go for it, I don't mind at all !> > Thank you !> > Lucas.
Awesome, thanks! I have created a "riscv" branch on both duskos and
duskos-deployments repositories with your v4 patches in it and I could get it
running.
For anyone trying, you have to create a symlink replacing the "duskv4"
directory in duskos-deployments (this repo also has a "riscv" branch) which
targets a directory where you have the duskos "riscv" branch checked out. You
*also* have to comment the line invoking "tar" in duskos-deployments'
common.mk. Then you can run "make riscvrun".
I know nothing about RISC-V, so before I go further, I need to read about it,
but it shouldn't be very long until I begin bridging that branch with your v5
patch, then going forward with the upgrade. This is exciting!
I was wondering about the context of that work. You've been writing this as
part of your work at INSA Lyon? Would it make sense to list them as sponsors in
the SPONSORS file? I was thinking that it would make sense to also include
sponsors for work I didn't author myself in there.
Regards,
Virgil
Hello Virgil,
Am 13.11.2024 um 16:30 schrieb Virgil Dupras:
> I think I'll like this ISA...
The only thing you might dislike is its immediate encoding. Bits are
shuffled to fit between the other parts, and in case your assembler
implements the "li" instruction (to load a 32-bit immediate value), it
needs to split the immediate across two instructions slots, one slot
holding the upper 20 bits (zero-extended to the right) and the other
slot holding the lower 12 bits (*sign* extended to the left, just like
regular 12-bit immediate values), which get added (not ORed). So if the
MSB of the lower 12 bits is set, the upper part needs to be corrected by
one.
This is all RV32, for RV64 it gets more hairy. Or you can just ignore
all this and put large immediates somewhere in memory and load them via
load instructions into a scratch register.
Still, this ISA is a lot cleaner than other contemporary instruction set
architectures, possibly excluding those used in academics (like MMIX or
DLX or Oberon RISC), especially as long as you focus on RV32I without
too many extensions.
Just my 2¢,
Michael
On Wed, Nov 13, 2024 at 11:13:46AM +0100, Lucas Chaloyard wrote:
> Hello Virgil,> > Sounds great to me ! Can't wait to see you work on it.> If you have any questions regarding anything, you can ask me, I'll try to> answer quickly.> > There is 3 patches :> > riscv-v4.patch => Add the RISC-V port to a DuskOS repo on v4 tag> > riscv-v4-deploymennts.patch => Add the RISC-V port deployment to a> duskos-deployments repo on commit 78d8d0de3b490b87ec95180e4d15a87fbbebb125> > > riscv-v4tov5.patch => It should patch correctly on a DuskOS repo with> RISC-V port added on v4 and then rebased to v5> > I've tested them on a cleaned version of your repos, so it should be easy to> patch.> > A few things to know :> 1. I added signed comparison operators to the boot.fs, because I used them> in the RISC-V assembler.> 2. 1-byte jump/branch instructions in RISC-V can go over 1 MB, so when> porting the kernel I decided to mainly used a 2-byte sequence of> instructions allowing to jump further, but now I'm not sure it was truly> necessary.> 3. RISC-V instruction set encoding is quite different from ARM (and i386 I> guess), so our assemblers might be quite different too, but you can ask me> anything about it.> > And if you see any possible upgrades of fixes to be done on the code I> wrote, go for it, I don't mind at all !> > Thank you !> > Lucas.
As of now, riscv branches in both duskos and duskos-deployment repos target v5
with all tests passing. There really wasn't much left to do, the bulk of the
work had been done.
So now I'll move the changes made to xcomp/boot to asm/riscv to facilitate
merging then carry on with v6:v13. We'll see later what to do with those signed
comparison words.
Regards,
Virgil
On Mon, Oct 07, 2024 at 09:25:57AM -0400, Virgil Dupras wrote:
> But all in all, the amount of work involved should be minor> compared to what you've done so far.
With the current "riscv" branches in duskos and duskos-deployment repos now up
to v8, I have to walk back on my previous statement quoted above. When I wrote
this, I only considered HAL changes.
It's not minor because there's not only HAL changes involved. All the fluff
concerning "packaging", that is, code change in Dusk that requires adjustments
in duskos-deployments is so far heavier than HAL changes. The BWM removal and
de-namespacization, which required adjustments in driver code, were also
something.
I can go through these changes at a pretty good pace because I remember those
changes, but I imagine that had you done them Lucas, it would have slowed you
down a lot and generated significant frustration. So it's a good thing I'm
doing them...
Regards,
Virgil
Hi Virgil,
Well thank you for doing what could have been a hard work for me !
I'm glad to hear that it's already up to v8, and I hope you don't have
too much trouble working on my work.
A good part of the port was simple translation from ARM instructions to
RISC-V instructions, but still, there were some spots (specifically HAL
operands) where I had to do some workarounds.
The major one would be the use of two allocated registers (named Acmp
and Bcmp, can be renamed) to store registers that we want to compare
(using compare,) and doing the comparison later, when executing the
branch instruction.
Now that you're at least a bit familiar with RISC-V, we can also discuss
about the ISA extensions used.
QEMU emulate a core using RV32GC, which is a set of several extensions,
the main one being RV32I.
But I also used RV32M for multiplication/division, which could be
avoided, if done like in ARM port, making the RISC-V port using only the
RV32I extension.
Honestly I don't have much take on that question, I'm not aware enough
of the existing RISC-V platforms, and if most (or all) of them are at
least using RV32GC, or if some of them are restricted to RV32I.
Thank you again for your work !
Lucas.
On Mon, Nov 18, 2024 at 09:57:20AM +0100, Lucas Chaloyard wrote:
> Hi Virgil,> > Well thank you for doing what could have been a hard work for me !> > I'm glad to hear that it's already up to v8, and I hope you don't have too> much trouble working on my work.
Already at v12 now, almost done :)
> A good part of the port was simple translation from ARM instructions to> RISC-V instructions, but still, there were some spots (specifically HAL> operands) where I had to do some workarounds.> > The major one would be the use of two allocated registers (named Acmp and> Bcmp, can be renamed) to store registers that we want to compare (using> compare,) and doing the comparison later, when executing the branch> instruction.
Yes, I've had time to get acquainted with this. Good idea. Considering that the
HAL is designed for CPUs with compare flags, there wasn't many options!
But this is costly, especially for ops with the Z flags. I've been thinking of
an optimization for when the upgrade is done: making Acmp and Bcmp compile time
register assignments. Instead of registers, it becomes variables that link to
registers.
For example, "A) &) compare," at *compile* time, set Acmp to xA and Bcmp to
xTOS. It writes *nothing*. Then "Z) brc," compiles the equivalent of "beq) xA
rs1) xTOS rs2)".
For this to work, the HAL needs a small redesign, specifically remove a
flag guarantee[1]. Without this, I think it will work, what do you think?
> Now that you're at least a bit familiar with RISC-V, we can also discuss> about the ISA extensions used.> QEMU emulate a core using RV32GC, which is a set of several extensions, the> main one being RV32I.> But I also used RV32M for multiplication/division, which could be avoided,> if done like in ARM port, making the RISC-V port using only the RV32I> extension.> Honestly I don't have much take on that question, I'm not aware enough of> the existing RISC-V platforms, and if most (or all) of them are at least> using RV32GC, or if some of them are restricted to RV32I.
I don't know about that either, but it seems to me that assuming "M" is alright.
SiFive's smallest machine[2], which has only 16K of RAM so not enough to run
Dusk without a memory addon, has a E31 core which is RV32IMAC.
> > Thank you again for your work !> > Lucas.
Thanks to you too, RISC-V support is nice! Your code is pretty good too, it
holds well to the upgrade process, it didn't reveal any HAL bug. The assembler
is nice.
Regards,
Virgil
[1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/hal.txt#L193
[2]: https://www.sifive.com/boards/hifive1-rev-b
> Already at v12 now, almost done :)
That's great ! You're working pretty fast.
Is v13 the version in which you rewrote the HAL in Forth ?
> For this to work, the HAL needs a small redesign, specifically remove a> flag guarantee[1]. Without this, I think it will work, what do you think?
It seems a pretty good idea to me, because yes this is pretty costy.
At first I wanted to give RISC-V "compare," a behavior similar to the
one on ARM and i386, which is that comparison is done on values set at
the moment of the comparison instruction, in order to have a safe
"compare,".
But like you say in the HAL doc, flags should be considered preserved
only right after the instruction updating the flags. So I don't see a
reason to not do it like you say. And also it makes a great use of
RISC-V absence of flags !
Will it have a big impact to remove the preservation guarantee from [1] ?
> I don't know about that either, but it seems to me that assuming "M" is alright.> SiFive's smallest machine[2], which has only 16K of RAM so not enough to run> Dusk without a memory addon, has a E31 core which is RV32IMAC.
If you are looking for a physical RISC-V platform to run DuskOS onto,
you might want to take a look in the Raspberry Pi Pico 2, which has 512K
of RAM I think.
> Thanks to you too, RISC-V support is nice! Your code is pretty good too, it> holds well to the upgrade process, it didn't reveal any HAL bug. The assembler> is nice.
Well, thanks ! I think some work can be done on the assembler, I wasn't
very satisfied with it in the end.
My understanding of RISC-V ISA wasn't complete when I started writing it
and I think it shows in the assembler source code.
I might try to rework on it when I have some free time.
Lucas.
[1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/hal.txt#L193
On Mon, Nov 18, 2024 at 04:15:57PM +0100, Lucas Chaloyard wrote:
> That's great ! You're working pretty fast.> Is v13 the version in which you rewrote the HAL in Forth ?
Yes. Should be fun.
> But like you say in the HAL doc, flags should be considered preserved only> right after the instruction updating the flags. So I don't see a reason to> not do it like you say. And also it makes a great use of RISC-V absence of> flags !> > Will it have a big impact to remove the preservation guarantee from [1] ?
I don't think so. I'll have to do a bit or archeology, but I vaguely remember
that I added this paragraph for a single use case and I don't remember ever
using that capability again. So I think the impact will be minimal.
> Well, thanks ! I think some work can be done on the assembler, I wasn't very> satisfied with it in the end.> My understanding of RISC-V ISA wasn't complete when I started writing it and> I think it shows in the assembler source code.
It's true that it could be refactored a bit, but the overall design is sound.
Wait until I'm done upgrading, I have a few tweaks to the assembler in the
pipeline.
Regards,
Virgil
Hello Lucas, all,
I'm almost done with the upgrade process. The riscv branch is already merged
with master, but during the upgrade, I postponed a couple of test failures,
knowing that they would be easier to fix later, so I disabled those tests.
Now's the time to re-enable them. There aren't many of them, I expect to be
done tomorrow, which means I'll be able to merge RISC-V support in the master
branch.
I haven't Forth-ified all of RISC-V's HAL. v13 does enable HAL forthifications,
but doesn't mandate them. I only Forth-ified the "constant" stuff as well as
the shift instructions[1] I'm thinking that with RISC-V kept in sync in master,
there's no urgency since the port will be kept in sync "naturally". I could
leave the rest of the Forth-ification work to you, what do you think?
There's also the matter of documentation. What I'm thinking of doing is to stub
out doc pages as TODO, mark RISC-V as Work In Progress and let you come up with
patches when you have time to work on them, without urgency. Meanwhile, I keep
that RISC-V WIP in sync while I work on the rest of Dusk. Sounds good to you?
Regards,
Virgil
[1]: they needed the Z flag to pass newest tests, so I figure that I might as
well Forth-ify them before improving them.
Sabrez le champagne! RISC-V is merged in the master branch. All tests pass.
The corresponding deployment is currently in the "wip" branch in
duskos-deployments. Therefore, someone wanting to try RISC-V before v14 is
released would checkout the "wip" branch, delete the "duskos-v13" directory and
replace it with a symlink to a checkout of dusk's master branch. Then, running
"make" in the "riscv" folder will build and run a RISC-V Dusk inside QEMU.
Onwards,
Virgil
Hello Virgil,
Félicitation and thank you for the great work !
Sorry for the delayed answer, I'll try to take a look at the riscv port
in v13, I'm excited to see what you come up with.
About your previous email, this seems a pretty good way of working from
now on, I can't make pretty promises about the amount of work I'll be
able to put it in, but I'll try to find some free time to work on it for
sure !
I'll at least try to write the documentation pretty soon, it should be
pretty straight-forward since I have the equivalent in my personal notes.
Thank you again for the hard work you put in this !
Lucas.