[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sbcl-devel
Subject:    Re: [Sbcl-devel] x86/split lock detection
From:       Douglas Katzman via Sbcl-devel <sbcl-devel () lists ! sourceforge ! net>
Date:       2022-04-28 2:09:30
Message-ID: CAOrNasx=ySV8EWKpvEu6YvEimRCFJpDgVi7XWJzX+Sh1__7QYA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


I think we can replace the cmpxchg with an ordinary mov. It's probably not
technically any more correct using cmpxchg. I do not see in the processor
manual that it guarantees to fetch instructions atomically across cache
lines; only that if an instruction was prefetched and then you store into
that address it must invalidate the prefetch. So my comment claiming that
there seems to be some atomicity seems misguided.
In any event I want to eliminate FDEFNs for symbols, and eliminate the
requirement for code to be in immobile space, so when i go down that road
I'm likely to redesign this anyway.
FDEFNs can be dispensed with for symbols because every symbol has 1 word
that can hold a raw address. (We already handle symbols differently in GC
due to the encoded package so no big deal to decode a raw word). And it's
not onerous to require that all functions in a symbol be callable as if it
were a SIMPLE-FUN - I need make-simplifying-trampoline to work universally
first.

[Attachment #5 (text/html)]

<div dir="ltr"><div dir="ltr">I think we  can replace the cmpxchg with an ordinary \
mov. It&#39;s probably not technically any more correct using cmpxchg. I do not see \
in the processor manual  that it guarantees to fetch instructions atomically across \
cache lines; only that if an instruction was prefetched and then you store into that \
address it must invalidate the prefetch. So my comment claiming that there seems to \
be some atomicity seems misguided.<div>In any event I want to eliminate FDEFNs for \
symbols, and eliminate the requirement for code to be in immobile space, so when i go \
down that road I&#39;m likely to redesign this anyway.</div><div>FDEFNs can be \
dispensed with for symbols because every symbol has 1 word that can hold a raw \
address. (We already handle symbols differently in GC due to the encoded package so \
no big deal to decode a raw word). And it&#39;s not onerous to require  that all \
functions in a symbol be callable as if it were a SIMPLE-FUN - I need \
make-simplifying-trampoline to work universally first.</div></div></div>





_______________________________________________
Sbcl-devel mailing list
Sbcl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel


[prev in list] [next in list] [prev in thread] [next in thread]