Vm-dev July 2022

vm-dev@lists.squeakfoundation.org

15 participants
78 discussions

[OpenSmalltalk/opensmalltalk-vm] Unable to rebind keyboard device in vm-display-fbdev (FrameBuffer) (#575)
by Ken Dickey 11 Jul '22

11 Jul '22

With libevdev, mouse and keyboard are bound to devices in /dev/input with names like "event0" and "event1". Different keyboard/mouse hw binds to different numbers, so it is important to allow overrides via shell variables. E.g. SQUEAK_MSDEV=/dev/input/event1 SQUEAK_KBDEV=/dev/input/event0 vs SQUEAK_MSDEV=/dev/input/event0 SQUEAK_KBDEV=/dev/input/event1 Mouse rebinding works, but not keyboard rebinding. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/575

1 2

VM Maker: VMMaker.oscog-eem.3206.mcz
by commits＠source.squeak.org 08 Jul '22

08 Jul '22

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.3206.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.3206 Author: eem Time: 8 July 2022, 2:27:26.170283 pm UUID: 0a5185d7-f6b0-46a3-a4ba-cbbf410bfdfd Ancestors: VMMaker.oscog-eem.3205 Add BitsAsWords for SmartSyntaxPlgins that want to coerce any bits object into unsigned int *'s. Use symbols for types in the SmartSyntax type class hierarchy where the type strings atre typicalled used as symbols. =============== Diff against VMMaker.oscog-eem.3205 =============== Item was changed: ----- Method: Array class>>ccgDeclareCForVar: (in category '*VMMaker-plugin generation') ----- ccgDeclareCForVar: aSymbolOrString + ^#'sqInt *', aSymbolOrString! - ^'sqInt *', aSymbolOrString! Item was added: + Behavior subclass: #BitsAsWords + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'VMMaker-SmartSyntaxPlugins'! + + !BitsAsWords commentStamp: 'eem 7/8/2022 13:56' prior: 0! + Coercion specification for bits objects like ByteString, Bitmap, ByteArray, WordArray, LargePositiveInteger et al to unsigned int *! Item was added: + ----- Method: BitsAsWords class>>ccg:prolog:expr:index: (in category 'plugin generation') ----- + ccg: cg prolog: aBlock expr: aString index: anInteger + + ^cg + ccgLoad: aBlock + expr: aString + asUnsignedPtrFrom: anInteger + andThen: (cg ccgValBlock: 'isWordsOrBytes')! Item was added: + ----- Method: BitsAsWords class>>ccgCanConvertFrom: (in category 'plugin generation') ----- + ccgCanConvertFrom: anObject + + ^anObject class isBits! Item was added: + ----- Method: BitsAsWords class>>ccgDeclareCForVar: (in category 'plugin generation') ----- + ccgDeclareCForVar: aSymbolOrString + + ^#'unsigned int *', aSymbolOrString! Item was changed: ----- Method: ByteArray class>>ccgDeclareCForVar: (in category '*VMMaker-plugin generation') ----- ccgDeclareCForVar: aSymbolOrString + ^#'char *', aSymbolOrString! - ^'char *', aSymbolOrString! Item was changed: ----- Method: DoubleByteArray class>>ccgDeclareCForVar: (in category '*VMMaker-plugin generation') ----- ccgDeclareCForVar: aSymbolOrString "Address of an unsigned 16 bit value, regardless of Smalltalk wordSize" + ^#'unsigned short *', aSymbolOrString! - ^'unsigned short *', aSymbolOrString! Item was changed: ----- Method: DoubleWordArray class>>ccgDeclareCForVar: (in category '*VMMaker-plugin generation') ----- ccgDeclareCForVar: aSymbolOrString "Address of an unsigned 64 bit value, regardless of Smalltalk wordSize" + ^#'unsigned long long *', aSymbolOrString! - ^'unsigned long long *', aSymbolOrString! Item was changed: ----- Method: Float class>>ccgDeclareCForVar: (in category '*VMMaker-plugin generation') ----- ccgDeclareCForVar: aSymbolOrString + ^#double, ' ', aSymbolOrString! - ^'double ', aSymbolOrString! Item was changed: ----- Method: Float32Array class>>ccgDeclareCForVar: (in category '*VMMaker-plugin generation') ----- ccgDeclareCForVar: aSymbolOrString + ^#'float *', aSymbolOrString! - ^'float *', aSymbolOrString! Item was changed: ----- Method: IntegerArray class>>ccgDeclareCForVar: (in category '*VMMaker-plugin generation') ----- ccgDeclareCForVar: aSymbolOrString + ^#'int *', aSymbolOrString! - ^'int *', aSymbolOrString! Item was changed: ----- Method: Object class>>ccgDeclareCForVar: (in category '*VMMaker-plugin generation') ----- ccgDeclareCForVar: aSymbolOrString + ^#sqInt, ' ', aSymbolOrString! - ^'sqInt ', aSymbolOrString! Item was changed: ----- Method: Oop class>>ccgDeclareCForVar: (in category 'plugin generation') ----- ccgDeclareCForVar: aSymbolOrString + ^#sqInt, ' ', aSymbolOrString! - ^'sqInt ', aSymbolOrString! Item was changed: ----- Method: SmartSyntaxPluginAssignmentCodeGenerator>>ccgLoad:expr:asOopPtrFrom:andThen: (in category 'coercing') ----- ccgLoad: aBlock expr: aString asOopPtrFrom: stackIndex andThen: valBlock + ^self assign: aString coerceTo: #'sqInt *' from: stackIndex! - ^self assign: aString coerceTo: 'sqInt *' from: stackIndex! Item was changed: ----- Method: SmartSyntaxPluginAssignmentCodeGenerator>>ccgLoad:expr:asUnsignedLong64PtrFrom:andThen: (in category 'coercing') ----- ccgLoad: aBlock expr: aString asUnsignedLong64PtrFrom: stackIndex andThen: valBlock + ^self assign: aString coerceTo: #'unsigned long long *' from: stackIndex! - ^self assign: aString coerceTo: 'unsigned long long *' from: stackIndex! Item was changed: ----- Method: SmartSyntaxPluginAssignmentCodeGenerator>>ccgLoad:expr:asUnsignedPtrFrom:andThen: (in category 'coercing') ----- ccgLoad: aBlock expr: aString asUnsignedPtrFrom: stackIndex andThen: valBlock + ^self assign: aString coerceTo: #'unsigned *' from: stackIndex! - ^self assign: aString coerceTo: 'unsigned *' from: stackIndex! Item was changed: ----- Method: SmartSyntaxPluginAssignmentCodeGenerator>>ccgLoad:expr:asUnsignedShortPtrFrom:andThen: (in category 'coercing') ----- ccgLoad: aBlock expr: aString asUnsignedShortPtrFrom: stackIndex andThen: valBlock + ^self assign: aString coerceTo: #'unsigned short *' from: stackIndex! - ^self assign: aString coerceTo: 'unsigned short *' from: stackIndex! Item was changed: ----- Method: String class>>ccgDeclareCForVar: (in category '*VMMaker-plugin generation') ----- ccgDeclareCForVar: aSymbolOrString + ^#'char *', aSymbolOrString! - ^'char *', aSymbolOrString! Item was changed: ----- Method: Unsigned class>>ccgDeclareCForVar: (in category 'plugin generation') ----- ccgDeclareCForVar: aSymbolOrString + ^ #'usqIntptr_t', ' ', aSymbolOrString! - ^'usqIntptr_t ', aSymbolOrString! Item was changed: ----- Method: WordArray class>>ccgDeclareCForVar: (in category '*VMMaker-plugin generation') ----- ccgDeclareCForVar: aSymbolOrString "Address of an unsigned 32 bit value, regardless of Smalltalk wordSize" + ^#'unsigned *', aSymbolOrString! - ^'unsigned *', aSymbolOrString! Item was changed: Behavior subclass: #WordsOrBytes instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'VMMaker-SmartSyntaxPlugins'! + !WordsOrBytes commentStamp: 'eem 7/8/2022 13:55' prior: 0! + Coercion specification for bits objects like ByteString, Bitmap, ByteArray, WordArray, LargePositiveInteger et al to char *! - !WordsOrBytes commentStamp: '' prior: 0! - Coercion specification for bits objects like ByteString, Bitmap, ByteArray, WordArray, LargePositiveInteger et al! Item was changed: ----- Method: WordsOrBytes class>>ccgDeclareCForVar: (in category 'plugin generation') ----- ccgDeclareCForVar: aSymbolOrString + ^#'char *', aSymbolOrString! - ^'char *', aSymbolOrString! Item was changed: ----- Method: WordsOrShorts class>>ccgDeclareCForVar: (in category 'plugin generation') ----- ccgDeclareCForVar: aSymbolOrString + ^#'short *', aSymbolOrString! - ^'short *', aSymbolOrString!

1 0

Possible bug in #primAtEnd: on MacOS and Linux
by Juan Vuletich 07 Jul '22

07 Jul '22

Hi Folks, A Cuis user, Nicola Mingotti, in some app specific code, needed to read stuff from a file while some other process writes to it. This Squeak snippet simulates what he did, and a problem I found: StandardFileStream forceNewFileNamed: 'test.txt' do: [ :fs | ]. reader := StandardFileStream fileNamed: 'test.txt'. Transcript cr; print: reader atEnd. StandardFileStream fileNamed: 'test.txt' do: [ :fs | fs nextPutAll: 'stuff']. Transcript cr; print: reader atEnd. reader close. Transcript cr; flush This is the equivalent code for Cuis. path := 'test.txt'. path asFileEntry fileContents: ''. fs := path asFileEntry readStream . fs atEnd print. path asFileEntry appendContents: 'stuff'. fs atEnd print. nil Evaluating any of these, in Windows I get printed 'true' then 'false', the correct answer. But on Ubuntu and MacOS, I get 'true' then 'true'. If I modify #atEnd not to call #primAtEnd: atEnd "Answer whether the receiver is at its end." collection ifNotNil: [ position < readLimit ifTrue: [ ^false ] ]. "^self primAtEnd: fileID" ^self position = self size I get the correct answer in all three platforms. This is a bug in the primitive, right? Thanks, -- Juan Vuletich www.cuis-smalltalk.org https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev https://github.com/jvuletich https://www.linkedin.com/in/juan-vuletich-75611b3 https://independent.academia.edu/JuanVuletich https://www.researchgate.net/profile/Juan-Vuletich https://patents.justia.com/inventor/juan-manuel-vuletich https://twitter.com/JuanVuletich

1 0

[OpenSmalltalk/opensmalltalk-vm] Feature Request: Add buildstamp to release assets (Issue #610)
by Christoph Thiede 07 Jul '22

07 Jul '22

My download folder looks pretty cluttered with names such as `squeak.cog.spur_win64x64 (3).zip`. I think it is a best practice to include the version/timestamp name of a build into the asset names. Could we maybe change the asset names to something like `osvm_202112201228_squeak.cog.spur_win64x64.zip`? -- Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/610 You are receiving this because you are subscribed to this thread. Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/610(a)github.com>

3 4

Squeak 6 on Mac
by Eliot Miranda 07 Jul '22

07 Jul '22

Hi all, apologies for raining on the parade. Here's what I get when I either launch the Squeak6 app bundle or drop an image on it. How can this be fixed? It's not a good default. [image: image.png] _,,,^..^,,,_ best, Eliot

5 18

VM/image backwards compatibility (& high dpi) [was Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn]
by Eliot Miranda 06 Jul '22

06 Jul '22

Hi Jaromir, > On May 11, 2022, at 5:49 AM, Jaromir Matas <mail(a)jaromir.net> wrote: > > > > Hi Eliot, > > > > On Tue, May 10, 2022 at 1:36 PM Jaromir Matas <mail(a)jaromir.net> wrote: > > > Hi Eliot, > > > > > > Thanks a lot for your answers. > > > > > > One last question: what about Process >> #signalException:? You wrote a fix (enclosed) – is it ok to merge it when the #suspend method is updated (Nicolas’s way)? > > > > > > > Yes, I think so. We have to test it but it seems right. And we can go even simpler, just have the first clause as guarded by processSuspensionUnblocks ifFalse:, once we're ready to release on VMs with the new primitive. > > > > Thanks again; this brings me to another question: if you go simpler, i.e. with the ifFalse clause only, it would mean the method wouldn't work correctly with older VMs with the older prim 88 suspend semantics. I was under the impression to keep compatibility with older VMs but maybe it's a nonsensical assumption on my part (The reason I'm asking is the #terminate I wrote is compatible with both the new and old VMs - but could be simplified a bit if the old VMs were not supposed to be used with the new images). That’s the way backwards compatibility works, with images and VMs in the same way as binaries and processors. A VM is expected to be backwards compatible with all older images of the same basic version (eg the Spur format, the V3 format). So all Spur 4.6, 5.x & current 6.x images should run on the current tip VM. But a new image may expect a feature added to a contemporary VM that is absent in previous versions of the VM. This is analogous to, for example, binaries compiled against newer instructions added to the x86 such as mmx, sse 1, 2 & 3. We expect that the new processor can run older binaries; we do not expect new binaries to run on older processors unless we compile them specially. Now, at a major release we may decide to remove VM features, but at that point we would change the VM’s image format number so that older images do not load. Since this effectively introduces a new VM variant it is not something we do lightly and do only when compelling, as the performance and functionality improvements obtained from the Spur architecture are over V3. We’re currently thinking about this with high dpi support. Can we afford to provide backwards compatibility with older “high dpi unaware” (HDU) images or not? We can either freeze Spur VM support for older images at around March this year, and drop support for HDU images in the platform sources, or we can add a flag bit to the image flags in the latest VMs which if set identifies an image as “high dpi aware” (HDA), and set the bit, eg in a Monticello package load script. And then the VM can remain backwards compatible by testing the HDA bit, behaving like older VMs if unset. It is desirable to maintain backwards compatibility if we can afford the engineering effort. But note that considerable engineering effort must be extended either way. For example, the Virtend application would require considerable work to migrate to HDA, being HDU currently. This is a structural issue. Putting the effort into the HDA VM to provide backwards compatibility with HDU images supports all older HDU applications. Not putting the effort means that all older HDU applications must put effort in to move forwards. (This is because the VM is the platform supporting applications above it, just as the trunk image is a platform that supports applications built within it). Hence it’s my preference to put the effort into the VM (selfishly as I’m committed to keeping the Virtend application running). What kinds of effort are we talking about? It’s not just having a flag to test and having the VM answer/respond appropriately for HDU if unset and for HDA if set. The flag needs to be tested very early in start up, potentially in the current sources before the image has been loaded. Eg on Linux one can supply a command line argument specifying the display subsystem to use which comes before the image name. So command line parsing must be able to make a pass through the arguments to find the image, locate the flags in the header, determine the value of the HDA flag, and then go back and actually process the command line arguments. Tedious work ;-) > > Thanks, > > Jaromir > > -- > Jaromír Matas > mail(a)jaromir.net > > From: Eliot Miranda > Sent: Tuesday, May 10, 2022 23:21 > To: The general-purpose Squeak developers list > Subject: Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn > > > > On Tue, May 10, 2022 at 1:36 PM Jaromir Matas <mail(a)jaromir.net> wrote: > Hi Eliot, > > Thanks a lot for your answers. > > One last question: what about Process >> #signalException:? You wrote a fix (enclosed) – is it ok to merge it when the #suspend method is updated (Nicolas’s way)? > > Yes, I think so. We have to test it but it seems right. And we can go even simpler, just have the first clause as guarded by processSuspensionUnblocks ifFalse:, once we're ready to release on VMs with the new primitive. > > > Thanks again, > Jaromir > > -- > > Jaromír Matas > > +420 777 492 777 > mail(a)jaromir.net > > > From: Eliot Miranda > Sent: Tuesday, May 10, 2022 21:17 > To: The general-purpose Squeak developers list > Subject: Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn > > Hi Jaromir, > > On Tue, May 10, 2022 at 8:31 AM Jaromir Matas <mail(a)jaromir.net> wrote: > Hi Eliot, Nicolas, > > > > > (Eliot) Apologies for not responding sooner. It seems to me the semantics must remain as they are, and it be left up to the image to bind suspend to the primitive most convenient. Then backwards compatibility can be provided for cases such as DelayWaitTimeout by providing a renamed suspend which accesses the old primitive. > > > > > > (Nicolas) Yes, I propose the selector > > Process>>suspendAndUnblock <primitive: 78> snip... > > Process>>suspend would call the new primitive, and fallback to suspendAndUnblock in case of failure (for example if new primitive is absent). > > The question remaining is if we really need two new primitives 578 (V1) and 588 (V2). > > It seems like signalException: would require V1, while Jaromir terminate logic would require V2... > > > > (Eliot) +1. Works for me. Having both 578 & 588 available in the VM is fine. I agree that surfacing only one of them is best. > > Thank you, I wasn't sure how to proceed with this :) Do I understand correctly #suspend will have the new suspend semantics (either V1 or preferably V2) in new images (new release) and the previous semantics (via prim 88) will be available for backward compatibility (or special usage)? > > Yes, exactly. > In that case the tests I submitted in KernelTests-jar.421 should work without changes... > > Cool! > > The next question is what to do with: > Process >> suspendPrimitivelyOrFail > "Test support. Execute primitive 88, or fail." > > <primitive: 88> > ^self primitiveFailed > > Change it or remove it? Replace with Nicolas’s Process>>suspendAndUnblock ? > > Well it appears to be used only in testAtomicSuspend. So I would change it to use the same primitive number as suspend, which I guess is 578, primitiveSuspendBackingUpV2, which has the more consistent semantics. > > > Thanks! > > Best, > > Jaromir > > From: Eliot Miranda > Sent: Monday, May 9, 2022 23:23 > To: The general-purpose Squeak developers list > Subject: Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn > > > > > On May 9, 2022, at 1:04 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > Hi Eliot, > Le lun. 9 mai 2022 à 20:36, Eliot Miranda <eliot.miranda(a)gmail.com> a écrit : > Hi Jaromir, Hi Nicolas, > > On Sun, May 8, 2022 at 8:17 AM Jaromir Matas <mail(a)jaromir.net> wrote: > Hi Nicolas, > > >> About the latest VM, (Smalltalk processSuspensionUnblocks) answers about the behavior of primitiveSuspend (#88). > > Err, wrong wording (Smalltalk processSuspensionUnblocks) does not describe the behavior of primitiveSuspend #(88). > > It answers whether the VM has primitives #578 and #588 (see #getCogVMFeatureFlags in VMMaker)... > > > Yes, thanks, well that was the original idea for Smalltalk processSuspensionUnblocks to answer about the behavior of the primitiveSuspend #88; which was before the primitives #568 and #578 were introduced. (And which was when I wrote the tests using this original logic). However that approach ran into problems with some existing implementations (e.g. Virtend) and as a result the two new primitives were introduced (#568 and #578) - and apparently the logic of what Smalltalk processSuspensionUnblocks answers about changed. Since then I haven't heard from Eliot about his plans how to proceed with the new suspend semantics or whether this is it :) > > Apologies for not responding sooner. It seems to me the semantics must remain as they are, and it be left up to the image to bind suspend to the primitive most convenient. Then backwards compatibility can be provided for cases such as DelayWaitTimeout by providing a renamed suspend which accesses the old primitive. > Yes, I propose the selector > Process>>suspendAndUnblock <primitive: 78> snip... > Process>>suspend would call the new primitive, and fallback to suspendAndUnblock in case of failure (for example if new primitive is absent). > The question remaining is if we really need two new primitives 578 (V1) and 588 (V2). > It seems like signalException: would require V1, while Jaromir terminate logic would require V2... > > +1. Works for me. Having both 578 & 588 available in the VM is fine. I agree that surfacing only one of them is best. > > > > Sorry about not renaming processSuspensionUnblocks. This should be something like Smalltalk hasExtendedProcessSuspensionSemantics or some such. > > It's not too late, there are not many usages, except inbox experimentations. > > > > > In case this is still WIP I'd quite like an approach similar to Smalltalk processPreemptionYields - you'd set Smalltalk processSuspensionUnblocks true or false depending on how you want the VM to behave and the VM would use the right semantics (unless this is too naive :) ). > > Regarding the tests failing with the newest VM: > testAtomicSuspend - we can remove this updated version and leave the existing one for the moment > testRevisedSuspendExpectations - we can leave this one out too > testTerminateBlockedInNestedEnsure1 - I'll take a look at these two and try to adjust the logic > testTerminateBlockedInNestedEnsure2 > > All remaining test in KernelTests-jar.421 work as intended. > > Thanks again, > Jaromir > > -- > > Jaromír Matas > > mail(a)jaromir.net > > > From: Nicolas Cellier > Sent: Sunday, May 8, 2022 16:22 > To: The general-purpose Squeak developers list > Subject: Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn > > > > Le dim. 8 mai 2022 à 15:59, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> a écrit : > > > Le dim. 8 mai 2022 à 14:16, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> a écrit : > Hi Jaromir > > Le sam. 7 mai 2022 à 14:45, Jaromir Matas <mail(a)jaromir.net> a écrit : > Hi Marcel, Nicolas, Eliot, > > > > (Nicolas) I have merged Kernel-jar.1446 which is trivial (re-signal an Exception). > > Thanks! > > > (Marcel) Hmm... #testSimpleResignalVsOuter1 is still failing. > > In my latest trunk image it passes ok (5/7/22) > > >> (Marcel) I will also take a look at KernelTests-jar.421 to check whether any new semantics are okay. > >> > > (Nicolas) Yes, I did that and got two failing tests > > testTerminateTerminatingProcess > > testResumeTerminatingProcess > > > > both failures look the same, in second self assert: terminator isSuspended. > > Yes, they are supposed to fail at the moment so I suggest to make them expected failures/feature requests. However there's a stupid bug in both I’ve fixed now: they were indeed supposed to fail the following assertion: > ``` self should: [terminatee terminate] raise: Error. ``` > > Apologies for the confusion - an updated changeset is enclosed. > > > However, there's another issue regarding the revised #suspend semantics Eliot has been working on. I've updated the process tests in KernelTests-jar.421 to test both the old and the new #suspend semantics. The two semantics should be distinguishable via Smalltalk processSuspensionUnblocks flag answering true in case of the old semantics and false in case of the revised one; my updated tests use this logic. However, unfortunately the latest VM answers "false" but uses the OLD suspend semantics in #suspend prim 88. > > So I'm surprised you haven't observed more tests failing due to the new suspend semantics... What VM have you used – an older one? I'm on the latest trunk's VM 3183. And what is the answer of Smalltalk processSuspensionUnblocks? :) I'm utterly confused... > > Hi Eliot - I may be confused here but if the current VM uses the old #suspend prim 88 semantics, shouldn't ```Smalltalk processSuspensionUnblocks``` answer true? > > > Indeed, I can confirm that the latest VM does answer false to (Smalltalk processSuspensionUnblocks). > Though, process suspension still unblocks as shown by the example at > https://github.com/pharo-project/pharo/issues/10669 > > A bit more simply, this answers false - it shouldn't: > > s := Semaphore new. > p := [s wait] newProcess. > p resume. > 100 milliSeconds wait. > p suspend; resume. > 100 milliSeconds wait. > p isTerminated = Smalltalk processSuspensionUnblocks. > > technically, this answers false - it shouldn't: > > s := Semaphore new. > p := [s wait] newProcess. > p resume. > 100 milliSeconds wait. > p suspend == s = Smalltalk processSuspensionUnblocks > > > About the latest VM, (Smalltalk processSuspensionUnblocks) answers about the behavior of primitiveSuspend (#88). > Err, wrong wording (Smalltalk processSuspensionUnblocks) does not describe the behavior of primitiveSuspend #(88). > It answers whether the VM has primitives #578 and #588 (see #getCogVMFeatureFlags in VMMaker)... > > The new Behavior is implemented by primitiveSuspendBackingUpV1 (#578) and primitiveSuspendBackingUpV2 (#588). > V1 always answers the old list (even if a Semaphore/Mutex), V2 answers nil in case of Semaphore/Mutex. > > So, only ((Process>>#suspend) primitive) can give you a clue about the behavior, assuming that the primitive in question is implemented... > > So it depends if we want to make it a Preference, or make the image compatible with some less capable VM... > > we could implement > Process>>primitiveSuspendAndUnblock as <primitive: 88> > Process>>primitiveSuspend as <primitive: 588> > test the VM flag in suspend > Process>>suspend > ^(VMHasPrimitiveSuspendBackingUp ifNil: [VMHasPrimitiveSuspendBackingUp := Smalltalk processSuspensionUnblocks not]) > ifTrue: [self primitiveSuspend] > ifFalse: [self primitiveSuspendAndUnblock] > Then arrange to reset VMHasPrimitiveSuspendBackingUp to nil at snapshot... > > I will tell next week about the status of the VM which I used for testing, it's possibly a few months old. > > > (Nicolas) I would also consider 1445 1421 and most importantly 1447. > > Regarding 1421: alternatively, you might consider a newer version 1415 where the only difference is #return:from: passes a block instead of nil to #resume:through: to cause a fresh search for the first unwind context; otherwise they are equivalent. > > OK, I will check again. > > > (Marcel) Maybe we can just merge > > > > KernelTests-jar.393 > > KernelTests-jar.418 > > KernelTests-jar.421 > > > > And go from there? Or are there any objections? > > KernelTests-jar.393 is just a special case of a more general KernelTests-jar.418 test… > > In my image all tests are green provided Smalltalk processSuspensionUnblocks answers true and the two above tests Nicolas mentioned are marked expected failures :) > > Thanks very much for your feedback, > Jaromir > > -- > > Jaromír Matas > > mail(a)jaromir.net > > > > > > > -- > _,,,^..^,,,_ > best, Eliot > > > > > > > -- > _,,,^..^,,,_ > best, Eliot > > > > > -- > _,,,^..^,,,_ > best, Eliot > >

2 3

VM Maker: VMMaker.oscog-eem.3205.mcz
by commits＠source.squeak.org 03 Jul '22

03 Jul '22

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.3205.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.3205 Author: eem Time: 3 July 2022, 10:54:24.223522 am UUID: 624993bc-bfc4-483f-b63b-a8b035905d5f Ancestors: VMMaker.oscog-eem.3204 ThreadedRiscV64FFIPlugin contributed by Ken Dickey; thankyou!! =============== Diff against VMMaker.oscog-eem.3204 =============== Item was added: + ThreadedFFICalloutStateForARM64 subclass: #ThreadedFFICalloutStateForRiscV64 + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'VMMaker-Plugins-FFI'! + + !ThreadedFFICalloutStateForRiscV64 commentStamp: 'KenD 6/27/2022 10:21' prior: 0! + A ThreadedFFICalloutStateForRiscV64 leverages the ARM64 code + ! Item was added: + ----- Method: ThreadedFFICalloutStateForRiscV64>>initialize (in category 'initialize-release') ----- + initialize + super initialize. + integerRegisterIndex := floatRegisterIndex := 0. + integerRegisters := CArrayAccessor on: (Array new: ThreadedRiscV64FFIPlugin numIntRegArgs). + floatRegisters := CArrayAccessor on: (Array new: ThreadedRiscV64FFIPlugin numFloatRegArgs)! Item was changed: ----- Method: ThreadedFFIPlugin class>>preambleCCode (in category 'translation') ----- preambleCCode "For a source of builtin defines grep for builtin_define in a gcc release config directory. See platforms/Cross/vm/sqCogStackAlignment.h for per-platform definitions for STACK_ALIGN_BYTES MUST_ALIGN_STACK, getsp, et al." ^' #include "sqAssert.h" /* for assert */ #define ThreadedFFIPlugin 1 /* to filter-out unwanted declarations from sqFFI.h */ #include "sqFFI.h" /* for logging and surface functions */ #include "sqCogStackAlignment.h" /* for STACK_ALIGN_BYTES and getsp() */ #ifdef _MSC_VER # define alloca _alloca #endif #if !!defined(setsp) && defined(__GNUC__) # if defined(_X86_) || defined(i386) || defined(__i386) || defined(__i386__) # define setsp(spval) asm volatile ("movl %0,%%esp" : : "m"(spval)) # elif defined(__amd64__) || defined(__x86_64__) || defined(__amd64) || defined(__x86_64) # define setsp(spval) asm volatile ("movq %0,%%rsp" : : "m"(spval)) # elif defined(__arm64__) || defined(__aarch64__) || defined(ARM64) /* https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm * http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/index.… */ # define setsp(spval) asm volatile ("mov sp, %0" : : "r"(spval)) # elif defined(__arm__) # define setsp(spval) asm volatile ("ldr %%sp, %0" : : "m"(spval)) + # elif defined(__riscv64__) || defined(__rv64g__) || defined(__rv64gcv__) + # define setsp(spval) asm volatile ("addi sp, %0, 0 " : : "r"(spval) : ) + # define getsp() asm volatile ("addi a0, sp, 0 " ) # endif #endif #if !!defined(getsp) # define getsp() 0 #endif #if !!defined(setsp) # define setsp(ignored) 0 #endif #if !!defined(STACK_ALIGN_BYTES) # define STACK_ALIGN_BYTES 0 #endif /* !!defined(STACK_ALIGN_BYTES) */ /* For ABI that require stack alignment greater than natural word size */ #define MUST_ALIGN_STACK (STACK_ALIGN_BYTES > sizeof(void*)) #if defined(_X86_) || defined(i386) || defined(__i386) || defined(__i386__) /* Both Mac OS X x86 and Win32 x86 return structs of a power of two in size * less than or equal to eight bytes in length in registers. Linux never does so. */ # if __linux__ # define WIN32_X86_STRUCT_RETURN 0 # else # define WIN32_X86_STRUCT_RETURN 1 # endif # if _WIN32 # define PLATFORM_API_USES_CALLEE_POPS_CONVENTION 1 # endif #elif defined(__amd64__) || defined(__x86_64__) || defined(__amd64) || defined(__x86_64) # if _WIN32 | _WIN64 # define PLATFORM_API_USES_CALLEE_POPS_CONVENTION 1 # endif #endif /* defined(_X86_) || defined(i386) || defined(__i386) || defined(__i386__) */ #if !!defined(ALLOCA_LIES_SO_SETSP_BEFORE_CALL) # if defined(__MINGW32__) && !!defined(__clang__) && (__GNUC__ >= 3) && (defined(_X86_) || defined(i386) || defined(__i386) || defined(__i386__)) /* * cygwin -mno-cygwin (MinGW) gcc 3.4.x''s alloca is a library routine that answers * %esp + xx, so the outgoing stack is offset by one or more word if uncorrected. * Grab the actual stack pointer to correct. */ # define ALLOCA_LIES_SO_SETSP_BEFORE_CALL 1 # else # define ALLOCA_LIES_SO_SETSP_BEFORE_CALL 0 # endif #endif /* !!defined(ALLOCA_LIES_SO_SETSP_BEFORE_CALL) */ #if !!defined(PLATFORM_API_USES_CALLEE_POPS_CONVENTION) # define PLATFORM_API_USES_CALLEE_POPS_CONVENTION 0 #endif /* The dispatchOn:in:with:with: generates an unwanted call on error. Just squash it. */ #define error(foo) 0 /* sanitize */ #ifdef SQUEAK_BUILTIN_PLUGIN # define EXTERN #else # define EXTERN extern #endif '! Item was added: + ThreadedARM64FFIPlugin subclass: #ThreadedRiscV64FFIPlugin + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'VMMaker-Plugins-FFI'! + + !ThreadedRiscV64FFIPlugin commentStamp: 'KenD 6/27/2022 10:22' prior: 0! + A ThreadedRiscV64FFIPlugin is for the RV64g RISC-V ABI. [Leverage ARM64 code] + + Stack grows Down; 16 byte aligned + 32 integer and 32 double float registers + x0 - always Zero [Thread swap shadow uses slot for PC] + x1 - Return Address (RA) + x2 - Stack Pointer (SP) + x8 - Frame Pointer (FP) - aka S0 + Argument registers: 8 integer and 8 float (float args in float regs) + A0..A7 = x10..x17 ; FA0..FA7 = f10..f17 + In RV64 sizeof(long) = sizeof(long long) = 8 = sizeof(void *) + Args larger than (void *) pointer are passed by reference. + Conceptually, args as fields of C struct with pointer alignment; + more args than # arg regs passed on stack with SP pointing + to 1st arg not passed in a register. + Values returned in A0/A1 or FA0/FA1 + Larger return values are placed in space alloc'ed by caller, + with pointer passed as implicit 1st parameter. + S1..S11 Save: CallEE Saved Registers (floats: FS0..FS11) + T0..T6 Temp: CalleR Saved Registers (floats: FT0..FT11) + + Bytes C type Description + 1 char Character value/byte + 2 short Short integer + 4 int Integer + 8 long Long integer + 8 long long Long long integer + 8 void* Pointer + 4 float Single-precision float + 8 double Double-precision float + 16 long double Extended-precision float + See + https://riscv.org/technical/specifications/ + https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf + ! Item was added: + ----- Method: ThreadedRiscV64FFIPlugin class>>calloutStateClass (in category 'translation') ----- + calloutStateClass + + ^ThreadedFFICalloutStateForRiscV64! Item was added: + ----- Method: ThreadedRiscV64FFIPlugin class>>excludingPredefinedMacros (in category 'translation') ----- + excludingPredefinedMacros + + ^#('__ARM_ARCH_ISA_A64' '__aarch64__' '__arm64__' 'ARM64' '_M_ARM64')! Item was added: + ----- Method: ThreadedRiscV64FFIPlugin class>>identifyingPredefinedMacros (in category 'translation') ----- + identifyingPredefinedMacros + + ^#('__riscv64__') ! Item was added: + ----- Method: ThreadedRiscV64FFIPlugin class>>initialize (in category 'class initialization') ----- + initialize + super initialize. + NumIntRegArgs := 8. + NumFloatRegArgs := 8! Item was added: + ----- Method: ThreadedRiscV64FFIPlugin class>>moduleName (in category 'translation') ----- + moduleName + + ^'RiscV64FFIPlugin'! Item was added: + ----- Method: ThreadedRiscV64FFIPlugin>>ffiCall:ArgArrayOrNil:NumArgs: (in category 'callout support') ----- + ffiCall: externalFunction ArgArrayOrNil: argArrayOrNil NumArgs: nArgs + "Generic callout. Does the actual work. If argArrayOrNil is nil it takes args from the stack + and the spec from the method. If argArrayOrNil is not nil takes args from argArrayOrNil + and the spec from the receiver." + | flags argTypeArray address argType oop argSpec argClass err theCalloutState calloutState requiredStackSize stackSize allocation result primNumArgs | + <inline: true> + <var: #theCalloutState type: #'CalloutState'> + <var: #calloutState type: #'CalloutState *'> + <var: #allocation type: #'char *'> + + primNumArgs := interpreterProxy methodArgumentCount. + (interpreterProxy is: externalFunction KindOfClass: interpreterProxy classExternalFunction) ifFalse: + [^self ffiFail: FFIErrorNotFunction]. + "Load and check the values in the externalFunction before we call out" + flags := interpreterProxy fetchInteger: ExternalFunctionFlagsIndex ofObject: externalFunction. + interpreterProxy failed ifTrue: + [^self ffiFail: FFIErrorBadArgs]. + + "This must come early for compatibility with the old FFIPlugin. Image-level code + may assume the function pointer is loaded eagerly. Thanks to Nicolas Cellier." + address := self ffiLoadCalloutAddress: externalFunction. + interpreterProxy failed ifTrue: + [^0 "error code already set by ffiLoadCalloutAddress:"]. + + argTypeArray := interpreterProxy fetchPointer: ExternalFunctionArgTypesIndex ofObject: externalFunction. + "must be array of arg types" + ((interpreterProxy isArray: argTypeArray) + and: [(interpreterProxy slotSizeOf: argTypeArray) = (nArgs + 1)]) ifFalse: + [^self ffiFail: FFIErrorBadArgs]. + "check if the calling convention is supported" + self cppIf: COGMTVM + ifTrue: + [(self ffiSupportsCallingConvention: (flags bitAnd: FFICallTypesMask)) ifFalse: + [^self ffiFail: FFIErrorCallType]] + ifFalse: "not masking causes threaded calls to fail, which is as they should if the plugin is not threaded." + [(self ffiSupportsCallingConvention: flags) ifFalse: + [^self ffiFail: FFIErrorCallType]]. + + requiredStackSize := self externalFunctionHasStackSizeSlot + ifTrue: [interpreterProxy + fetchInteger: ExternalFunctionStackSizeIndex + ofObject: externalFunction] + ifFalse: [-1]. + interpreterProxy failed ifTrue: + [^interpreterProxy primitiveFailFor: (argArrayOrNil isNil + ifTrue: [PrimErrBadMethod] + ifFalse: [PrimErrBadReceiver])]. + stackSize := requiredStackSize < 0 ifTrue: [DefaultMaxStackSize] ifFalse: [requiredStackSize]. + self cCode: [] inSmalltalk: [theCalloutState := self class calloutStateClass new]. + calloutState := self addressOf: theCalloutState. + self cCode: [self memset: calloutState _: 0 _: (self sizeof: #CalloutState)]. + calloutState callFlags: flags. + "Fetch return type and args" + argType := interpreterProxy fetchPointer: 0 ofObject: argTypeArray. + argSpec := interpreterProxy fetchPointer: 0 ofObject: argType. + argClass := interpreterProxy fetchPointer: 1 ofObject: argType. + (err := self ffiCheckReturn: argSpec With: argClass in: calloutState) ~= 0 ifTrue: + [^self ffiFail: err]. "cannot return" + "alloca the outgoing stack frame, leaving room for marshalling args, and including space for the return struct, if any. + Additional space reserved for saving register args like mandated by Win64 X64 or PPC ABI, will be managed by the call itself" + allocation := self alloca: stackSize + calloutState structReturnSize + self cStackAlignment. + self mustAlignStack ifTrue: + [allocation := self cCoerce: (allocation asUnsignedIntegerPtr bitClear: self cStackAlignment - 1) to: #'char *']. + calloutState + argVector: allocation; + currentArg: allocation; + limit: allocation + stackSize. + "This next bit overrides the ARM64 code to pass return struct pointer in A0" + (calloutState structReturnSize > 0 + and: [self nonRegisterStructReturnIsViaImplicitFirstArgument + and: [(self returnStructInRegisters: calloutState) not]]) ifTrue: + [err := self ffiPushPointer: calloutState limit in: calloutState. + err ~= 0 ifTrue: + [self cleanupCalloutState: calloutState. + self cppIf: COGMTVM ifTrue: + [err = PrimErrObjectMayMove negated ifTrue: + [^PrimErrObjectMayMove]]. "N.B. Do not fail if object may move because caller will GC and retry." + ^self ffiFail: err]]. + "Aside from the bit above, code identical with arn64" + 1 to: nArgs do: + [:i| + argType := interpreterProxy fetchPointer: i ofObject: argTypeArray. + argSpec := interpreterProxy fetchPointer: 0 ofObject: argType. + argClass := interpreterProxy fetchPointer: 1 ofObject: argType. + oop := argArrayOrNil isNil + ifTrue: [interpreterProxy stackValue: nArgs - i] + ifFalse: [interpreterProxy fetchPointer: i - 1 ofObject: argArrayOrNil]. + err := self ffiArgument: oop Spec: argSpec Class: argClass in: calloutState. + err ~= 0 ifTrue: + [self cleanupCalloutState: calloutState. + self cppIf: COGMTVM ifTrue: + [err = PrimErrObjectMayMove negated ifTrue: + [^PrimErrObjectMayMove]]. "N.B. Do not fail if object may move because caller will GC and retry." + ^self ffiFail: err]]. "coercion failed or out of stack space" + "Failures must be reported back from ffiArgument:Spec:Class:in:. + Should not fail from here on in." + self assert: interpreterProxy failed not. + self ffiLogCallout: externalFunction. + (requiredStackSize < 0 + and: [self externalFunctionHasStackSizeSlot]) ifTrue: + [stackSize := calloutState currentArg - calloutState argVector. + interpreterProxy storeInteger: ExternalFunctionStackSizeIndex ofObject: externalFunction withValue: stackSize]. + "Go out and call this guy" + result := self ffiCalloutTo: address SpecOnStack: argArrayOrNil notNil in: calloutState. + self cleanupCalloutState: calloutState. + "Can not safely use argumentCount (via e.g. methodReturnValue:) since it may have been changed by a callback." + interpreterProxy pop: primNumArgs + 1 thenPush: result. + ^result! Item was added: + ----- Method: ThreadedRiscV64FFIPlugin>>nonRegisterStructReturnIsViaImplicitFirstArgument (in category 'marshalling') ----- + nonRegisterStructReturnIsViaImplicitFirstArgument + "Answer if a struct returned in memory is returned to the + referent of a pointer passed as an implciit first argument. + It almost always is. Subclasses can override if not." + ^true! Item was added: + ----- Method: ThreadedRiscV64FFIPlugin>>numFloatRegArgs (in category 'accessing') ----- + numFloatRegArgs + + ^NumFloatRegArgs! Item was added: + ----- Method: ThreadedRiscV64FFIPlugin>>numIntRegArgs (in category 'accessing') ----- + numIntRegArgs + + ^NumIntRegArgs! Item was added: + ----- Method: ThreadedRiscV64FFIPlugin>>wordSize (in category 'simulation support') ----- + wordSize + + ^ 8 "RiscV64g"!

1 0

Re: [Vm-dev] Help: Float returns on RISCV
by Jan Vrany 02 Jul '22

02 Jul '22

On Thu, 2022-06-30 at 18:03 -0400, Boris Shingarov wrote: > If you are interested, we can have a microhackathon where I can show you > *my* way of doing it (which means, ULD). Or maybe Jan wants to show you > his (which means, libgdbs/vdb). You were in the Pacific timezone, correct? > > Jan: How good/bad is the ArchC model for rv64 right now? I remember you > were fixing some defects around the register name conventions being all > wrong -- are those now better or there is more work needed before ULD > could even pick it up meaningfully? > ArchC model for RISC-V is good enough. At the moment it does not support A, F and D extensions, but that's "just work". Actually, I gave it a stab this morning and got F and D working in half an hour or so (modulo bugs). The RISC-V model is good - in the last VM hackathon I used RISC-V model to emit and run code on both QEMU and Unleashed. There's little work left on assembly/disaasembly support for flw/fld/fsw/fsd (but that's the asm syntax, one need to deal with the fact that one register is FPR and another is GPR) - but that's detail I can fix easily. As for ULD I'd think it will be fine, but I quite don't remember where and how we handle target description annex. We may need to work around CSRs, they're not (yet) modelled in (my) RISC-V ArchC model. > Would you be interested to also > participate in a GDB microhackathon with Ken? Sure, I'm always up for some debugging fun! Best, Jan > > On 6/30/22 15:23, ken.dickey(a)whidbey.com wrote: > > > > > Date: Wed, 29 Jun 2022 09:17:29 -0700 > > > From: Eliot Miranda <eliot.miranda(a)gmail.com> > > .. > > > The pattern is straight-forward. Look at the various implementations > > > of ffiCalloutTo:SpecOnStack:in:. There are two issues, passing > > > arguments and receiving results. > > > > Yes. I have followed that. Thanks. > > > > The generated RiscV64FFIPlugin.c is virtually identical to > > ARM64FFIPlugin.c as > > > > ThreadedARM64FFIPlugin subclass: #ThreadedRiscV64FFIPlugin with almost > > no overrides, > > > > aside from > > #nonRegisterStructReturnIsViaImplicitFirstArgument --> true. > > > > However, the post return assignment to floatRet.d which I see in the > > ARM64 code appears to be absent from the RiscV64 code. > > > > Being very rusty on C and GDB, I am moby confused by this.. > > -KenD > > > > vvvvvv======vvvvvv From SqueakFFIPlugin: > > [Aarch64/Arm64] > > > > 2470 (floatRet.d = > > dispatchFunctionPointerwithwithwithwithwithwithwithwith(((struct dprr > > (*)(sqIntptr_t, sqIntptr_t, sqIntptr_t, sqIntptr_t, sqIntptr_t, > > sqIntptr_t, sqIntptr_t, sqIntptr_t)) (((void *) address))), > > ((calloutState->integerRegisters))[0], > > ((calloutState->integerRegisters))[1], > > ((calloutState->integerRegisters))[2], > > ((calloutState->integerRegisters))[3], > > ((calloutState->integerRegisters))[4], > > ((calloutState->integerRegisters))[5], > > ((calloutState->integerRegisters))[6], > > ((calloutState->integerRegisters))[7])); > > 0x0000007ff6b3b6cc <+2004>: ldr x8, [x29, #928] > > 0x0000007ff6b3b6d0 <+2008>: ldr x0, [x29, #800] > > 0x0000007ff6b3b6d4 <+2012>: ldr x9, [x0, #232] > > 0x0000007ff6b3b6d8 <+2016>: ldr x0, [x29, #800] > > 0x0000007ff6b3b6dc <+2020>: ldr x1, [x0, #240] > > 0x0000007ff6b3b6e0 <+2024>: ldr x0, [x29, #800] > > 0x0000007ff6b3b6e4 <+2028>: ldr x2, [x0, #248] > > 0x0000007ff6b3b6e8 <+2032>: ldr x0, [x29, #800] > > 0x0000007ff6b3b6ec <+2036>: ldr x3, [x0, #256] > > 0x0000007ff6b3b6f0 <+2040>: ldr x0, [x29, #800] > > 0x0000007ff6b3b6f4 <+2044>: ldr x4, [x0, #264] > > 0x0000007ff6b3b6f8 <+2048>: ldr x0, [x29, #800] > > 0x0000007ff6b3b6fc <+2052>: ldr x5, [x0, #272] > > 0x0000007ff6b3b700 <+2056>: ldr x0, [x29, #800] > > 0x0000007ff6b3b704 <+2060>: ldr x6, [x0, #280] > > 0x0000007ff6b3b708 <+2064>: ldr x0, [x29, #800] > > 0x0000007ff6b3b70c <+2068>: ldr x7, [x0, #288] > > 0x0000007ff6b3b710 <+2072>: add x0, x29, #0x3b8 > > 0x0000007ff6b3b714 <+2076>: sub x19, x0, #0x200 > > 0x0000007ff6b3b718 <+2080>: mov x0, x9 > > 0x0000007ff6b3b71c <+2084>: blr x8 > > ## after return, struct floatRet.d is assigned > > 0x0000007ff6b3b720 <+2088>: fmov d5, d0 > > 0x0000007ff6b3b724 <+2092>: fmov d4, d1 > > 0x0000007ff6b3b728 <+2096>: fmov d1, d2 > > 0x0000007ff6b3b72c <+2100>: fmov d0, d3 > > 0x0000007ff6b3b730 <+2104>: str d5, [x19] > > 0x0000007ff6b3b734 <+2108>: str d4, [x19, #8] > > 0x0000007ff6b3b738 <+2112>: str d1, [x19, #16] > > 0x0000007ff6b3b73c <+2116>: str d0, [x19, #24] > > > > 2471 if (isCalleePopsConvention((calloutState->callFlags))) { > > ^^^^^^======^^^^^^ > > vvvvvv======vvvvvv > > [RISCV64] > > > > 2476 (floatRet.d = > > dispatchFunctionPointerwithwithwithwithwithwithwithwith(((struct dprr > > (*)(sqIntptr_t, sqIntptr_t, sqIntptr_t, sqIntptr_t, sqIntptr_t, > > sqIntptr_t, sqIntptr_t, sqIntptr_t)) (((void *) address))), > > ((calloutState->integerRegisters))[0], > > ((calloutState->integerRegisters))[1], > > ((calloutState->integerRegisters))[2], > > ((calloutState->integerRegisters))[3], > > ((calloutState->integerRegisters))[4], > > ((calloutState->integerRegisters))[5], > > ((calloutState->integerRegisters))[6], > > ((calloutState->integerRegisters))[7])); > > 0x0000003ff703f95a <+3456>: ld t3,-200(s0) > > 0x0000003ff703f95e <+3460>: ld a7,-208(s0) > > 0x0000003ff703f962 <+3464>: ld a6,-216(s0) > > 0x0000003ff703f966 <+3468>: ld a5,-224(s0) > > 0x0000003ff703f96a <+3472>: ld a4,-232(s0) > > 0x0000003ff703f96e <+3476>: ld a3,-240(s0) > > 0x0000003ff703f972 <+3480>: ld a2,-248(s0) > > 0x0000003ff703f976 <+3484>: ld a1,-256(s0) > > 0x0000003ff703f97a <+3488>: addi s4,s0,-520 > > 0x0000003ff703f97e <+3492>: mv a0,s4 > > 0x0000003ff703f980 <+3494>: sd t3,0(sp) > > 0x0000003ff703f982 <+3496>: jalr s5 > > > > ## NOTA BENE: After return: NO assignment to floatRet.d !?! > > > > 2477 if (isCalleePopsConvention((calloutState->callFlags))) { > > > > 2478 setsp((calloutState->argVector)); > > 2479 } > > 2480 ownVM(myThreadIndex); > > => 0x0000003ff703f984 <+3498>: ld a5,408(s10) > > 0x0000003ff703f988 <+3502>: mv a0,s1 > > 0x0000003ff703f98a <+3504>: jalr a5 > > > > 2481 if (atomicType == FFITypeDoubleFloat) { > > 0x0000003ff703f98c <+3506>: li a5,13 > > 0x0000003ff703f98e <+3508>: beq s2,a5,0x3ff703fd4a > > <ffiCallArgArrayOrNilNumArgs+4464> > > > > 2482 result = > > floatObjectOf(((((floatRet.d)).doubles))[0]); > > ^^^^^^======^^^^^^ > >

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev July 2022