Vm-dev December 2019

vm-dev@lists.squeakfoundation.org

31 participants
265 discussions

[OpenSmalltalk/opensmalltalk-vm] 0b7afb: For some reason buildspurtrunkreader64image.sh is ...
by Eliot Miranda 12 Dec '19

12 Dec '19

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 0b7afb6f6f12d477541f59c019f3434b4c97178c https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0b7afb6f6f12d47754… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2019-12-11 (Wed, 11 Dec 2019) Changed paths: M image/buildspurtrunkreader64image.sh Log Message: ----------- For some reason buildspurtrunkreader64image.sh is nonsense. Did it get overwritten? restore it to a functional state.

1 0

VM Maker: VMMaker.oscog-eem.2608.mcz
by commits＠source.squeak.org 12 Dec '19

12 Dec '19

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2608.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2608 Author: eem Time: 11 December 2019, 3:54:39.87751 pm UUID: 56d4f721-2b53-47a0-848a-845793297010 Ancestors: VMMaker.oscog-eem.2607 Fix poor code for locating the last jump in the PIC prototype. =============== Diff against VMMaker.oscog-eem.2607 =============== Item was changed: ----- Method: Cogit>>expectedClosedPICPrototype: (in category 'in-line cacheing') ----- expectedClosedPICPrototype: cPIC "Use asserts to check if the ClosedPICPrototype is as expected from compileClosedPICPrototype, and can be updated as required via rewriteCPICCaseAt:tag:objRef:target:. If all asserts pass, answer 0, otherwise answer a bit mask identifying all the errors." "self disassembleFrom: methodZoneBase + (self sizeof: CogMethod) to: methodZoneBase + closedPICSize" <var: #cPIC type: #'CogMethod *'> | pc errors object classTag entryPoint | errors := 0. pc := cPIC asUnsignedInteger + firstCPICCaseOffset. "First jump is unconditional; subsequent ones are conditional" object := backEnd literalBeforeFollowingAddress: pc - backEnd jumpLongByteSize. (self asserta: object = self firstPrototypeMethodOop) ifFalse: [errors := 1]. entryPoint := backEnd jumpLongTargetBeforeFollowingAddress: pc. (self asserta: entryPoint = (self cPICPrototypeCaseOffset + 16rCA5E10)) ifFalse: [errors := errors + 2]. 1 to: MaxCPICCases - 1 do: [:i | | methodObjPC classTagPC | pc := pc + cPICCaseSize. "verify information in case is as expected." methodObjPC := pc - backEnd jumpLongConditionalByteSize - backEnd cmpC32RTempByteSize. object := backEnd literalBeforeFollowingAddress: methodObjPC. (self asserta: object = (self subsequentPrototypeMethodOop+ i)) ifFalse: [errors := errors bitOr: 4]. classTagPC := pc - backEnd jumpLongConditionalByteSize. classTag := backEnd literal32BeforeFollowingAddress: classTagPC. (self asserta: classTag = (16rBABE1F15 + i)) ifFalse: [errors := errors bitOr: 8]. entryPoint := backEnd jumpLongConditionalTargetBeforeFollowingAddress: pc. (self asserta: entryPoint = (self cPICPrototypeCaseOffset + 16rCA5E10 + (i * 16))) ifFalse: [errors := errors bitOr: 16]. "change case via rewriteCPICCaseAt:tag:objRef:target:" self rewriteCPICCaseAt: pc tag: (classTag bitXor: 16r5A5A5A5A) objRef: (object bitXor: 16rA5A5A5A5) target: (entryPoint bitXor: 16r55AA50). "don't xor least 4 bits to leave instruction alignment undisturbed" "verify information in case is as expected post update." object := backEnd literalBeforeFollowingAddress: methodObjPC. (self asserta: object = (self subsequentPrototypeMethodOop + i bitXor: 16rA5A5A5A5)) ifFalse: [errors := errors bitOr: 32]. classTag := backEnd literal32BeforeFollowingAddress: classTagPC. (self asserta: classTag = (16rBABE1F15 + i bitXor: 16r5A5A5A5A)) ifFalse: [errors := errors bitOr: 64]. entryPoint := backEnd jumpLongConditionalTargetBeforeFollowingAddress: pc. (self asserta: entryPoint = ((self cPICPrototypeCaseOffset + 16rCA5E10 + (i * 16)) bitXor: 16r55AA50)) ifFalse: [errors := errors bitOr: 128]. "finally restore case to the original state" self rewriteCPICCaseAt: pc tag: (classTag bitXor: 16r5A5A5A5A) objRef: (object bitXor: 16rA5A5A5A5) target: (entryPoint bitXor: 16r55AA50)]. + entryPoint := backEnd jumpLongTargetBeforeFollowingAddress: cPIC asUnsignedInteger + cPICEndOfCodeOffset. - entryPoint := backEnd jumpLongTargetBeforeFollowingAddress: pc + cPICEndSize - literalsManager endSizeOffset. (self asserta: entryPoint = (self cPICMissTrampolineFor: 0)) ifFalse: [errors := errors + 256]. ^errors!

1 0

Re: [Vm-dev] [Pharo-dev] Debugging GCC code generation
by Eliot Miranda 11 Dec '19

11 Dec '19

Hi Pablo, On Wed, Dec 11, 2019 at 11:33 AM tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hi Nicolas, > thanks for the comment, you are right the problem is the bad > original code. But my opinion is that it just is not reporting the > situation correctly, generating a warning or non-optimizing the code > looks more like a expected behavior. Because as I have said, using a > constant as index in the last statement generates a meaningful warning > and the non-optimizated version of the function. > > And again as you said, the only thing to learn about all this is that > we should not write crappy code. > Hang on. "crappy code" is too strong. Back in tre ANSI days it was not undefined behavior, and in fact I think this only because undefined behavior because C compilers were faced with lots of code where variables were typed int but were being used on 64-bit machines. Had the C world used long as its default type then there would have been no need to make casting the address of a long into the address of an int undefined behavior. So this isn't crappy code (if you think of what it means in memory on a 64-bit little endnan machine it is perfectly sensible). It /is/ code that is inappropriate given C99. So yes, we have to bow to the C gods and generate C99 compliant code, but what we were doing here wasn't crappy, it was merely code that became undefined behavior so that C compilers could generate more efficient code for 64-bit systems in the presence of code that contains lots of integer variables declared as int. So let's just say that we have to generate C99 compliant code. You'll notice that the Smalltalk code in the original does exactly what you suggest Pablo. fetchLong32: fieldIndex ofFloatObject: oop "index by word size, and return a pointer as long as the word size" | bits | (self isImmediateFloat: oop) ifFalse: [^self fetchLong32: fieldIndex ofObject: oop]. bits := self smallFloatBitsOf: oop. ^self cCode: [(self cCoerceSimple: (self addressOf: bits) to: #'int *') at: fieldIndex] inSmalltalk: [self flag: #endian. fieldIndex = 0 ifTrue: [bits bitAnd: 16rFFFFFFFF] ifFalse: [bits >> 32]] > On Wed, Dec 11, 2019 at 7:11 PM Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > Of course, when I say "your" code, it's the code you have shown, and > probably "our" (VMMaker) code ;) > > > > Le mer. 11 déc. 2019 à 19:05, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> a écrit : > >> > >> Hi Pablo (again), > >> no, not a bug. > >> > >> The problem is in the source code. The compiler has the right to > presume that your code is exempt of UB, because you cannot depend on UB > (obviously). > >> So it can eliminate all code which corresponds to UB. > >> > >> The compiler has the right to assume that a pointer to an int cannot > point to a long (UB). > >> So modifying a long cannot have any sort of impact on the content of > the int pointer. > >> So the compiler can decouple both path return int content and assign > long. > >> But assigning the long has no effect, so the code can be suppressed > altogether. > >> > >> Le mer. 11 déc. 2019 à 18:54, tesonep(a)gmail.com <tesonep(a)gmail.com> a > écrit : > >>> > >>> Hi Aliaksei, > >>> to me it looks like a bug of GCC optimization. Basically, it is > >>> assuming that the x variable is used but never read or its value is > >>> never used. Also it assumes the same of the i variable, as we are only > >>> accessing indirectly to the memory where it locates (the code is even > >>> assuming that the variable exists, but it can be optimize out as in > >>> this scenario). Even though, the original C code is valid C code, we > >>> are not helping the compiler writing code like that. So I have > >>> rewritten the code in a way that does not use indirect memory access > >>> to the stack space. > >>> > >>> One thing more that makes me think is a bug, if you use an int > >>> constant as the index and not a parameter, the error does not occur > >>> (the code is not badly optimized) and there is a warning about the > >>> not-so-great access to the stack. > >>> > >>> On Wed, Dec 11, 2019 at 6:01 PM Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >>> > > >>> > Hi Pablo, > >>> > > >>> > Wow! Thank you for the detective story :) > >>> > > >>> > Do I understand correctly that the original code causes undefined > behavior and therefore can be changed (or even removed) by the compiler? > >>> > (because it returns something that is referencing memory on the > stack) > >>> > > >>> > Please keep posting similar things in future! It is very educative :) > >>> > > >>> > Cheers, > >>> > Alex > >>> > > >>> > > >>> > On Wed, 11 Dec 2019 at 17:35, tesonep(a)gmail.com <tesonep(a)gmail.com> > wrote: > >>> >> > >>> >> Hi, > >>> >> this mail is related to Pharo because it is knowledge I found > >>> >> debugging the build of the VM, but the rest is to document it and > >>> >> perhaps someone will found it interesting (also I couldn't find it > >>> >> easily using Google). Sorry for the long mail! > >>> >> > >>> >> The problem > >>> >> ========== > >>> >> > >>> >> The following code does not produce good code in 8.3 when using > optimizations: > >>> >> > >>> >> long __attribute__ ((noinline)) myFunc(long i, int index){ > >>> >> long v; > >>> >> long x = i >> 3; > >>> >> > >>> >> v = x; > >>> >> return ((int*)(&v))[index]; > >>> >> } > >>> >> > >>> >> #include <stdio.h> > >>> >> > >>> >> int main(){ > >>> >> > >>> >> long i; > >>> >> int x; > >>> >> > >>> >> scanf("%ld", &i); > >>> >> scanf("%d", &x); > >>> >> > >>> >> printf("%ld",myFunc(i,x)); > >>> >> } > >>> >> > >>> >> Basically, with -02, it generates the following code: > >>> >> > >>> >> myFunc: > >>> >> movslq %esi, %rsi > >>> >> movslq -8(%rsp,%rsi,4), %rax > >>> >> ret > >>> >> > >>> >> And with -01 it generates the following code: > >>> >> > >>> >> myFunc: > >>> >> sarq $3, %rdi > >>> >> movq %rdi, -8(%rsp) > >>> >> movslq %esi, %rsi > >>> >> movslq -8(%rsp,%rsi,4), %rax > >>> >> ret > >>> >> > >>> >> As you can see, the more optimized version is losing the bit shift > (or > >>> >> any other operation). > >>> >> To detect the problem it was not easy, basically, I have used the > >>> >> Pharo Tests to detect the failing function and then to understand > the > >>> >> generation of code in GCC, we need to debug its generation. > >>> >> > >>> >> The first snippet is generated using: > >>> >> > >>> >> gcc -O2 prb.c -S -o prb.s -Wall > >>> >> > >>> >> and the second using: > >>> >> > >>> >> gcc -O1 prb.c -S -o prb.s -Wall > >>> >> > >>> >> The GCC pipeline has different steps, I have centered my self in the > >>> >> tree optimizations. > >>> >> GCC dumps each of the intermediate states of the compilation, > working > >>> >> with C like trees. For example to get the optimized version of the > >>> >> program, before generating the Assembler we have to do: > >>> >> > >>> >> gcc -O2 prb.c -S -o prb.s -Wall -fdump-tree-optimized=/dev/stdout > >>> >> > >>> >> This will generate: > >>> >> > >>> >> __attribute__((noinline)) > >>> >> myFunc (long int i, int index) > >>> >> { > >>> >> long int v; > >>> >> long unsigned int _1; > >>> >> long unsigned int _2; > >>> >> int * _3; > >>> >> int _4; > >>> >> long int _8; > >>> >> > >>> >> <bb 2> [local count: 1073741825]: > >>> >> _1 = (long unsigned int) index_7(D); > >>> >> _2 = _1 * 4; > >>> >> _3 = &v + _2; > >>> >> _4 = *_3; > >>> >> _8 = (long int) _4; > >>> >> v ={v} {CLOBBER}; > >>> >> return _8; > >>> >> > >>> >> } > >>> >> > >>> >> This is the optimized SSA (static single assign) version of the > >>> >> function (https://gcc.gnu.org/onlinedocs/gccint/SSA.html) > >>> >> As you can see in this version the code is already optimized, and > our > >>> >> operations not correctly generated. We expect to see something like: > >>> >> > >>> >> __attribute__((noinline)) > >>> >> myFunc (long int i, int index) > >>> >> { > >>> >> long int x; > >>> >> long int v; > >>> >> long unsigned int _1; > >>> >> long unsigned int _2; > >>> >> int * _3; > >>> >> int _4; > >>> >> long int _10; > >>> >> > >>> >> <bb 2> [local count: 1073741825]: > >>> >> x_6 = i_5(D) >> 3; > >>> >> v = x_6; > >>> >> _1 = (long unsigned int) index_9(D); > >>> >> _2 = _1 * 4; > >>> >> _3 = &v + _2; > >>> >> _4 = *_3; > >>> >> _10 = (long int) _4; > >>> >> v ={v} {CLOBBER}; > >>> >> return _10; > >>> >> > >>> >> } > >>> >> > >>> >> In the first SSA version, we are lacking the shift operation: > >>> >> > >>> >> x_6 = i_5(D) >> 3; > >>> >> v = x_6; > >>> >> > >>> >> So, we need to see in which of the optimizations and transformations > >>> >> our code is lost: > >>> >> To see all the steps we should execute: > >>> >> > >>> >> gcc -O2 prb.c -S -o prb.s -Wall -fdump-tree-all > >>> >> > >>> >> This will generate a lot, really a lot, of files in the same > directory. > >>> >> They have the name: prb.c.xxx.yyyy > >>> >> Where xxx is the number of the step, and yyyy is the name of the > step. > >>> >> Each of the files contains the result of applying the changes, so > what > >>> >> I have done is looking in binary search where my code was lost. > >>> >> > >>> >> I have found that the problem was in the first dead code elimination > >>> >> step (prb.c.041t.cddce1) > >>> >> GCC does not like the crap code that we are writing, as we are > copying > >>> >> a stack variable and then accessing directly to the memory: > >>> >> > >>> >> v = x; > >>> >> return ((int*)(&v))[index]; > >>> >> > >>> >> So, basically, it was assuming that we were only using v and not x, > so > >>> >> all the code modifying x is described (this optimization is called > >>> >> "dead store code deletion"). Basically tries to remove all the code > >>> >> that is affecting stack (temporary) variables that are never used. > >>> >> > >>> >> I am not sure if this is a bug in GCC, so I will report it. But I > have > >>> >> fixed the problem writing the code in a proper way. > >>> >> > >>> >> Sorry again for the long mail, I wanted to store the knowledge and > >>> >> propagate it before I eventually will flush it. I like these things, > >>> >> but I am not debugging the GCC optimization pipeline all the days. > >>> >> > >>> >> -- > >>> >> Pablo Tesone. > >>> >> tesonep(a)gmail.com > >>> >> > >>> > >>> > >>> -- > >>> Pablo Tesone. > >>> tesonep(a)gmail.com > >>> > > > -- > Pablo Tesone. > tesonep(a)gmail.com > > -- _,,,^..^,,,_ best, Eliot

2 1

[OpenSmalltalk/opensmalltalk-vm] 9f3440: CogVM source as per Name: VMMaker.oscog-eem.2606
by Eliot Miranda 11 Dec '19

11 Dec '19

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 9f3440d7e35da0038df425e8a0966adbff80ab15 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9f3440d7e35da0038d… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2019-12-11 (Wed, 11 Dec 2019) Changed paths: M nsspur64src/vm/cointerp.c M nsspur64src/vm/cointerp.h M nsspur64src/vm/gcc3x-cointerp.c M spur64src/vm/cointerp.c M spur64src/vm/cointerp.h M spur64src/vm/cointerpmt.c M spur64src/vm/cointerpmt.h M spur64src/vm/gcc3x-cointerp.c M spur64src/vm/gcc3x-cointerpmt.c M spursista64src/vm/cointerp.c M spursista64src/vm/cointerp.h M spursista64src/vm/gcc3x-cointerp.c M spurstack64src/vm/gcc3x-interp.c M spurstack64src/vm/interp.c Log Message: ----------- CogVM source as per Name: VMMaker.oscog-eem.2606 Fix the "funny floats" issue with gcc et al. Casting the address of an automatic long to an int * is no longer allowed. Thanks to Pablo Tessone for the analysis and fix.

1 0

VM Maker: VMMaker.oscog-eem.2607.mcz
by commits＠source.squeak.org 11 Dec '19

11 Dec '19

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2607.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2607 Author: eem Time: 11 December 2019, 12:21:52.120098 pm UUID: 15c00de2-91a9-4e11-8545-be86f29c7d20 Ancestors: VMMaker.oscog-eem.2606 Fix a minor mis-formatting. =============== Diff against VMMaker.oscog-eem.2606 =============== Item was changed: ----- Method: CogARMCompiler>>instructionAddressBefore: (in category 'inline cacheing') ----- + instructionAddressBefore: mcpc + "Answer the instruction address immediately preceding mcpc." - instructionAddressBefore: followingAddress - "Answer the instruction address immediately preceding followingAddress." <inline: true> + ^mcpc - 4! - ^followingAddress -4!

1 0

VM Maker: VMMaker.oscog-eem.2606.mcz
by commits＠source.squeak.org 11 Dec '19

11 Dec '19

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2606.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2606 Author: eem Time: 11 December 2019, 12:08:45.007873 pm UUID: be1eac72-340a-4ed5-bfe7-6051597847a4 Ancestors: VMMaker.oscog-eem.2605 Fix the "funny floats" issue with gcc et al. Casting the address of an automatic long to an int * is no longer allowed. Thanks to Pablo Tessone for the analysis and fix. =============== Diff against VMMaker.oscog-eem.2605 =============== Item was changed: ----- Method: Spur64BitMemoryManager>>fetchLong32:ofFloatObject: (in category 'object access') ----- fetchLong32: fieldIndex ofFloatObject: oop "index by word size, and return a pointer as long as the word size" | bits | (self isImmediateFloat: oop) ifFalse: [^self fetchLong32: fieldIndex ofObject: oop]. bits := self smallFloatBitsOf: oop. + ^fieldIndex = 0 + ifTrue: [bits bitAnd: 16rFFFFFFFF] + ifFalse: [bits >> 32]! - ^self - cCode: [(self cCoerceSimple: (self addressOf: bits) to: #'int *') at: fieldIndex] - inSmalltalk: - [self flag: #endian. - fieldIndex = 0 - ifTrue: [bits bitAnd: 16rFFFFFFFF] - ifFalse: [bits >> 32]]!

1 0

Squeak Inspectors
by Eliot Miranda 11 Dec '19

11 Dec '19

Hi All, Clément and I were talking earlier today (about issues around the solving of issue 444) and later on we talked a it about UI. It has been a goal of Tudor Girba to have a VMMaker that uses the Glamorous Toolkit for richer inspection facilities, a project than makes sense to me too. But it is one I have failed to contribute to because of issues I have with Pharo. However, richer inspection could be implemented in Squeak too, without taking on the task of porting GT to Squeak (a worth-while project I encourage anyone interested to consider). So what would be required to do something slick in Squeak? I'm hacking up a few ideas right now but there are some things I'd like, and I'm not sure of how to get them, hence my sending the message here and cc'ing Marcel. One thing is handling double click in text so that it triggers not a selection, but some semantic action. I'm imagining a three column inspector where on the left are the inst vars of a VM object, such as the interpreter. In the next column is a default display of the selected inst var, for example, the output of the print: routine, which for the specialObjectsArray looks like this: 16r2FAF998: a(n) Array 16r734500 nil 16r734510 false 16r734520 true 16rD09B20 a Global #Processor -> 16r00745CD8 16rB01D20 class Bitmap 16r124FCB8 class SmallInteger 16rB02140 class ByteString 16rB01C00 class Array 16rB4D228 a SmalltalkImage 16r106E708 class BoxedFloat64 16rB05380 class Context 16r734500 nil 16rB04BA0 class Point 16rAFF358 class LargePositiveInteger 16r780B30 a DisplayScreen 16rB00018 class Message 16rB01F00 class CompiledMethod 16r2000B8 a Semaphore 16rB02440 class Semaphore 16rAFF4D8 class Character 16r93F0A8 #doesNotUnderstand: 16r93F0C8 #cannotReturn: 16r734500 nil 16r241C998 an Array 16r734500 nil 16r93F0E0 #mustBeBoolean 16rB01FC0 class ByteArray 16r116E800 class Process 16r2FB10B8 an Array 16r1365050 a Semaphore 16r100048 a Semaphore 16r734500 nil 16r734500 nil 16r734500 nil 16r980DF8 #cannotInterpret: 16r734500 nil 16rB192C0 class BlockClosure 16r734500 nil 16r100068 an Array 16r734500 nil 16r10AB350 a LinkedList 16r759080 a Semaphore 16rAFF2F8 class LargeNegativeInteger 16r2F82230 class ExternalAddress 16r2F820E8 class ExternalStructure 16r2F82D00 class ExternalData 16r2F88508 class ExternalFunction 16r2F82950 class ExternalLibrary 16r9B2090 #aboutToReturn:through: 16r9CB820 #run:with:in: 16r10BBBD0 #attemptToAssign:withIndex: 16r2FB10C8 an Array 16r2F4DF88 class Alien 16r10BBD20 #invokeCallbackContext: 16r2F51228 class UnsafeAlien 16r734500 nil 16r734500 nil 16rCE3570 #unusedBytecode 16r10BBBA0 #conditionalBranchCounterTrippedOn: 16r10BAB98 #classTrapFor: Then in the third column would be a sub-inspector, so that if one double-clicked in an oops in the above display, that would be displayed in the third column. Ideally the inspectors would cascade like they do in GT. But for the moment I'd be happy with anything that doesn't require copy/pasting oops (the hex numbers above) into dialog boxes to print further info in the transcript window in a simulation. So Marcel (& others who are interested), at the most basic level, how would one add a double-click action to our current Inspector framework to enable that kind of interaction? How would one build a cascading Inspector as per GT? And as impetus, this UI will help us develop the VM faster, and that will get you, in time, a faster VM. _,,,^..^,,,_ best, Eliot

4 6

VM Maker: VMMaker.oscog-eem.2605.mcz
by commits＠source.squeak.org 11 Dec '19

11 Dec '19

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2605.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2605 Author: eem Time: 10 December 2019, 8:37:01.148843 pm UUID: 9fa3b4e5-57c2-4bb6-b241-0b697c10618d Ancestors: VMMaker.oscog-eem.2604 Minor refactoring. =============== Diff against VMMaker.oscog-eem.2604 =============== Item was removed: - ----- Method: CogARMCompiler>>storeLiteral:beforeFollowingAddress: (in category 'inline cacheing') ----- - storeLiteral: literal beforeFollowingAddress: followingAddress - "Rewrite the long constant loaded by the instruction sequence just before this address:" - ^self subclassResponsibility! Item was added: + ----- Method: CogAbstractInstruction>>storeLiteral:beforeFollowingAddress: (in category 'inline cacheing') ----- + storeLiteral: literal beforeFollowingAddress: followingAddress + "Rewrite the long constant loaded by the instruction sequence just before this address:" + ^self subclassResponsibility!

1 0

VM Maker: VMMaker.oscog-eem.2604.mcz
by commits＠source.squeak.org 10 Dec '19

10 Dec '19

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2604.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2604 Author: eem Time: 10 December 2019, 12:20:47.039646 pm UUID: da1b7197-99c1-4482-b011-99cf9d2c78f5 Ancestors: VMMaker.oscog-eem.2603 A64: Implement simple scheme for aligning 64-bit literals in 32-bit granularity code. Later on we can try and introduce Liuteral and Literal32 and group Literal32's together for more compact code. Bit this is fine for now. =============== Diff against VMMaker.oscog-eem.2603 =============== Item was changed: ----- Method: CogARMCompiler>>callInstructionByteSize (in category 'accessing') ----- callInstructionByteSize + "ARMv8 calls and jumps span +/- 128 mb, more than enough for intra-zone calls and jumps." - "ARM calls and jumps span +/- 32 mb, more than enough for intra-zone calls and jumps." ^4! Item was added: + ----- Method: CogAbstractInstruction>>literalAlignment (in category 'accessing') ----- + literalAlignment + "Answer the required alignment for literals embedded in code. + Default to codeGranularity. Subclasses requiring greater must override" + <inline: true> + ^self codeGranularity! Item was changed: ----- Method: OutOfLineLiteralsManager>>dumpLiterals: (in category 'compile abstract instructions') ----- dumpLiterals: generateBranchAround + "Output all pending literal instructions, making the originals dependents on the generated ones + so that a later pass will copy the address of each generated literal inst to its original in literals, - "Output all pending literal instructions, making the originals dependents of the generated ones - so that a later pass will copy the address of each generated literl inst to its original in literals, and hence allow the instruction using the literal to compute the correct address.." | jump litInst | <var: 'jump' type: #'AbstractInstruction *'> <var: 'litInst' type: #'AbstractInstruction *'> generateBranchAround ifTrue: [jump := cogit Jump: 0]. + cogit backEnd literalAlignment > cogit backEnd codeGranularity ifTrue: + [cogit gen: AlignmentNops operand: cogit backEnd literalAlignment]. lastDumpedLiteralIndex to: nextLiteralIndex - 1 do: [:i| litInst := self literalInstructionAt: i. (cogit gen: Literal operand: (litInst operands at: 0)) dependent: litInst. litInst setLiteralOpcodeIndex: cogit getOpcodeIndex]. generateBranchAround ifTrue: [jump jmpTarget: cogit Label]. firstOpcodeIndex := cogit getOpcodeIndex. lastDumpedLiteralIndex := nextLiteralIndex!

1 0

[OpenSmalltalk/opensmalltalk-vm] Serious character-encoding bug (#449)
by Marcel Taeumel 10 Dec '19

10 Dec '19

![imagex](https://user-images.githubusercontent.com/5765308/70330556-1bb35d00-183e-11ea-9d14-3b0714e5bcf2.png) I am on Windows 10, German keyboard layout. Yesterday, I switched to OpenSmalltalk-VM version 201911282316, 32-bit. That issue might not be related to the Windows platform at all. Not sure. Here are the symptoms: - I cannot type German umlauts anymore (öäü) in a workspace - The Monticello patch browser finds strange diffs for things I did not touch Affected VM versions: - 201911282316 - 201911222128 - 201911220849 - 201911182135 - 201911160620 Last time it worked as expected was in 201911140217. -- 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/449

2 3

← Newer
1
...
19
20
21
22
23
24
25
26
27
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev December 2019