On 19-Oct-98 ralf@uni-koblenz.de wrote:
> On Sun, Oct 18, 1998 at 09:53:18PM +0200, Harald Koerfgen wrote:
[...]
> There is a number of machines, most popular some DECstation, which are
> available with both CPU architectures.
Yup.
> The other location for which patching might be useful are primarily the
> differences between the R3000 and R4000 status register, especially the
> KU rsp. KSU bits. What other places do you have in mind?
Agreed. There are indeed other places where code could be reintegrated,
r2300_switch.S and r4k_switch.S come to mind.
On the other hand, there is code which should be seperated for performance
reasons,
mainly the RESTORE_ALL macros thus affecting entry.S and scall_o32.S. Actually
these
problems are solved by conditional compiling.
>> To make those changes generic needs either a reasonable amount of hacking or
>> avoidable code duplication. In fact, if we really don't care about self
>> modifying code we should be able to remove some code duplication, for
>> example in the fpu stuff.
>
> People should consider that we'll be able to hide the self modifications
> in C code very nicely. I would not go for anything which I consider a
> maintenance problem or major uglyness.
Good.
> Let me explain how the approach from my recent patch works:
[explanation snipped]
> Todo: we don't want a separate section per patched instruction. Easy to
> fix. We also want to get rid of the special section just like other
> initfunc stuff.
That sounds great. We could even put all ISA dependant code into seperate
sections and get rid of all the ISA sections, which aren't needed.
> The next class of things to patch are the zillion of function calls using
> function pointers. We can insert a jal instruction and patch it's
> destination address. Candidates for that include calls to flush_cache_all,
> flush_cache_mm, flush_cache_range, flush_cache_page, flush_cache_sigtramp,
> flush_tlb_all, flush_tlb_mm, flush_tlb_range, flush_tlb_page, add_wired_entry,
> clear_page, copy_page.
>
> Both parts, patching immediate opperands and function calls can be dealt
> with similar to the approach in the userland dynamic linker, that initially
> the function called is the dynamic linker's kernel equivalent which will
> choose the right thing to do.
>
> Extra goodie for the R3000 fraction: Many functions called via above
> mentioned pointers are empty, calls to them may be eleminated by overwriting
> the calling jal with nops. Say goodbye to another hand full of cycles.
That sounds even better :-).
---
Regards,
Harald
|