To update those not closely watching commits; this got committed over the
weekend.
Quoth cinap_len...@felloff.net:
> just for reference the work-in-progress implementation for this on 9front
> amd64 kernel:
>
> https://felloff.net/usr/cinap_lenrek/pc64fpnote.patch
>
> needs some work around th
Lol! Well I'm sure someone will! Or will want to... :)
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Taf6b900592afc500-Md04eee609e574cc8fdae9845
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Sat, Mar 15, 2025 at 12:58 PM Alyssa M via 9fans <9fans@9fans.net> wrote:
> (I have to admit I'm still wondering what on Earth people are doing with
> floating point in note handlers.)
>
Are you saying I shouldn't be writing my note handlers in Javascript?
it's funny how old the problem of process trap handling is in computing.
On Sat, 15 Mar 2025 at 21:33, Charles Forsyth
wrote:
> (I have to admit I'm still wondering what on Earth people are doing with
>> floating point in note handlers.)
>
>
> i only ever used them to resume a process/coroutine
>
> (I have to admit I'm still wondering what on Earth people are doing with
> floating point in note handlers.)
i only ever used them to resume a process/coroutine/whatever. to be fair,
it's trickier since "fp" came to include integer vector instructions and
block moves
On Sat, 15 Mar 2025 at 1
Well, I tried this on my partly-implemented Plan 9 emulator. I sandwiched
Ureg+fpreg between argv and the TOS structure. So note handlers get a fixed
Ureg address that happens to have the fpregs after it. noted(2) is altered to
use the fixed address for Ureg. Plan 9 binaries don't have to change
Hi again,
I'd forgotten about libthread and stack space for Uregs. That's
unfortunate, especially because Intel keeps growing the size of the FP
regs. I'd rather not hard-code the expected size in binaries and then have
to deal with it growing again. It is starting to sound like a notefpregs
file
Is there ever a need for more than one active Ureg+fpreg per process? If not,
maybe it could be pre-allocated at TOS.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Taf6b900592afc500-M3d6119de5a43ce683af5a97c
Delivery options: https://9f
> If we're going down this route, we should copy the FPsave
> to the stack in notify as we do the Ureg. Then we wouldn't
> need the ofpregs file at all.
yeah. i'm not fond of it ofpregs-file solution eigther.
> This will require some thinking
> about backwards compatibility. There needs to be a
Hi Cinap,
I see what you are saying about wanting /proc/n/fpregs for both debuggers
vs note handlers themselves. I think debuggers are more likely, so fpregs
should be the current FP registers (if you're in a note handler, it's the
handler's registers). I would suggest /proc/n/notefpregs for the f
cinap_len...@felloff.net once said:
> There was never a Ureg* equivalent for the fpu state (being dumped on
> the user stack). However, i believe, as the fpu is being disabled
> during execution of the note handler, you could imaginge a handler
> using fpregs file to read/modify the fpu state.
>
>
just for reference the work-in-progress implementation for this on 9front amd64
kernel:
https://felloff.net/usr/cinap_lenrek/pc64fpnote.patch
needs some work around the devproc access to the fpsave structs
and maybe find an alternative to the #ifdef code... but otherwise
the handler part was eas
Thank you for your answer.
> I believe that /proc/$pid/regs is the note registers during
> the note handler, and so .../fpregs should be the same. I don't think we
> need fpregs and ofpregs, since we don't have regs and oregs.
I think that is mistaken. /proc/n/regs gives you the registers
of the
What I thought was a floating-point problem turned out to be an integer
problem: noted(NCONT) was smashing a few of the integer registers on its
way back to the original note context. Nothing to do with floats at all.
https://github.com/rsc/plan9/commit/aa00f938f6b3c6a5b4502c25605666f479a22c16
On
Well it's a 32bit processor, so vlong will be emulated partly in the runtime
library and partly by the compiler. If there's a bug there then an example
would be a contribution to science. :) I would still expect such a bug to
produce a reliable wrong answer or a crash - and not be perturbed by a
I dont think that vlong on arm32 raspberry pi works. And the code below use
vlong.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Taf6b900592afc500-M1808d84304068c0c09f6d580
Delivery options: https://9fans.topicbox.com/groups/9fans/subsc
good day.
i'v took a look at the patch:
https://github.com/rsc/plan9/commit/3715bf9b86a86ed6a3a857cabfc7dff5d70b409b
i spend some time yesterday trying to implement the
same behaviour in 9front kernels and it is not too
difficult, but the semantics would need to be clarified
and i'm not totally
17 matches
Mail list logo
