Hi,
On Mon Oct 23, 2017 at 01:50:47 +0200, Paul Boddie wrote:
A quick reply as it is rather late...
So often :)
On Monday 23. October 2017 00.55.53 Adam Lackorzynski wrote:
On Mon Oct 16, 2017 at 15:35:22 +0200, Paul Boddie wrote:
On Monday 16. October 2017 00.48.38 Adam Lackorzynski wrote:
You're talking about the cache instruction issue?
Yes (ci20-rdhwr.diff). I was also potentially interested in supporting other instructions that related SoCs do not support, at least where those do not
What I don't understand is why this needs to be done in asm. I'd favor something in C.
I haven't looked at how the floating point emulation is done in the Linux kernel, as another example of this kind of thing, but I imagine that you have
Linux has FP emulators to support applications with FPU code on processors that don't have an FPU. It does the obvious, catching the traps and handling them. Whether it's a good idea to do that in a microkernel is another thing. Technically it could be done of course but building the code with softfloat has always been a good alternative.
to do some assembly language programming here just to recover from the exception. In this case, however, the emulated instruction is very simple, although I did take the liberty of rearranging the emulation mechanism slightly.
Yes, it is probably simple but that does not necessarily mean it would need to be done in asm. Exceptions are caught and handled of course, the actual processing can be done in C.
In fact, someone with more familiarity than me with low-level MIPS programming could probably reproduce my patch with little effort, but I imagine that it isn't of significant interest any more.
[MIPS systems without floating point support]
Fiasco is typically built not using floating point, as most kernels. Which problem are you hinting at?
I was just wondering about use of floating point. If I can build user space programs that also don't need floating point then I save myself some work, potentially.
Exactly, and it will be faster too.
[...]
Thinking back, there was some uncertainty about whether it was appropriate to generate position-independent code when building Fiasco.OC, where I had introduced initialisation of t9 so that global offset table lookups functioned correctly (ci20-gcc-cpload.diff).
This diff addresses user-level programs, and are meant to have them being able to be compiled as PIC?
Yes. Various L4Re components do not work when compiled with gcc unless I introduce these changes. It was suggested that I do not compile such things as position-independent code, but I don't remember any further explanation.
Hmm, does that mean that with Debian's gcc (6? 7?) there might be issues?
I was rebasing my own large patch against an updated upstream repository, but other matters took priority and I haven't looked at it again. I had been trying to write a few device drivers for the CI20, specifically for GPIO, CPM and I2C, with the latter being unreliable and rather annoying.
I don't know but maybe the Ci40 is a better board, having interAptiv cores.
The CI40 is aimed at a different sector, being IoT-related rather than a desktop-style single-board computer. Indeed, the CI20 has 1GB RAM - far more than the CI40 - but some trickery appears necessary to make more than 256MB visible to Fiasco due to the physical memory map layout, but I haven't looked into this yet. Obviously, Linux can make use of all of the RAM.
For me, my interest in the CI20 is driven by its choice of SoC which is in the same family as various other products I have access to. I don't think I'll be buying another board for the time being: the CI20 is tangential enough to my core interests as it is.
Ok, I see, there's a background. And obviously the available memory can make a big difference.
Adam