[Vm-dev] VM Maker: VMMaker.oscog-tpr.1513.mcz

commits at source.squeak.org commits at source.squeak.org
Wed Nov 11 19:34:44 UTC 2015


tim Rowledge uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog-tpr.1513.mcz

==================== Summary ====================

Name: VMMaker.oscog-tpr.1513
Author: tpr
Time: 11 November 2015, 11:33:12.233 am
UUID: 6ff3cfa5-df00-4848-96ba-589d9ddeb05b
Ancestors: VMMaker.oscog-rmacnak.1512

Fix a couple of CPIC bugs and commetns.

=============== Diff against VMMaker.oscog-rmacnak.1512 ===============

Item was changed:
  ----- Method: CogARMCompiler>>callTargetFromReturnAddress: (in category 'inline cacheing') -----
  callTargetFromReturnAddress: callSiteReturnAddress
  	"Answer the address that the call immediately preceding callSiteReturnAddress will jump to."
  	"this is also used by #jumpLongTargetBeforeFollowingAddress:."
  	| callDistance call |
  	call := self instructionBeforeAddress: callSiteReturnAddress.
  	self assert: ((self instructionIsB: call) or: [self instructionIsBL: call]).
  	callDistance := self extractOffsetFromBL: call.
+ 	"this is the pc's +8 offset, - the 4 byte correction for the previous instruction address"
+ 	^callSiteReturnAddress + 4  + callDistance signedIntFromLong!
- 	^callSiteReturnAddress + 4 "this is the pc's +8 offset, - the 4 byte correction for the previous instruction address" + callDistance signedIntFromLong!

Item was removed:
- ----- Method: CogARMCompiler>>loadLiteralByteSize (in category 'accessing') -----
- loadLiteralByteSize
- 	"Answer the byte size of a MoveCwR opcode's corresponding machine code. On ARM this is a single instruction pc-relative register load - unless we have made a mistake and not turned on the out of line literals manager"
- 	^4!

Item was added:
+ ----- Method: CogInLineLiteralsARMCompiler>>loadLiteralByteSize (in category 'accessing') -----
+ loadLiteralByteSize
+ 	"Answer the byte size of a MoveCwR opcode's corresponding machine code. On ARM this is a single instruction pc-relative register load - unless we have made a mistake and not turned on the out of line literals manager"
+ 	^16!

Item was added:
+ ----- Method: CogOutOfLineLiteralsARMCompiler>>loadLiteralByteSize (in category 'accessing') -----
+ loadLiteralByteSize
+ 	"Answer the byte size of a MoveCwR opcode's corresponding machine code. On ARM this is a single instruction pc-relative register load - unless we have made a mistake and not turned on the out of line literals manager"
+ 	^4!

Item was changed:
  ----- Method: Cogit>>addressOfEndOfCase:inCPIC: (in category 'in-line cacheing') -----
  addressOfEndOfCase: n inCPIC: cPIC 
  	"calculate the end of the n'th case statement - which is complicated because we have case 1 right at the top of our CPIC and then build up from the last one. Yes I know this sounds strange, but trust me - I'm an Engineer, we do things backwards all the emit"
  
  	<var: #cPIC type: #'CogMethod *'>
  	self assert: (n >= 1and: [n <= maxCPICCases]).
+ 	^n = 1
+ 		ifTrue: [cPIC asInteger + firstCPICCaseOffset]
+ 		ifFalse: [cPIC asInteger + firstCPICCaseOffset + (maxCPICCases + 1 - n * cPICCaseSize)]!
- 	n = 1
- 		ifTrue: [^ cPIC asInteger + firstCPICCaseOffset]
- 		ifFalse: [^ cPIC asInteger + firstCPICCaseOffset + (maxCPICCases + 1 - n * cPICCaseSize)]!

Item was changed:
  ----- Method: Cogit>>cPIC:HasTarget: (in category 'in-line cacheing') -----
  cPIC: cPIC HasTarget: targetMethod
  	"Are any of the jumps from this CPIC to targetMethod?"
  	<var: #cPIC type: #'CogMethod *'>
  	<var: #targetMethod type: #'CogMethod *'>
  	| pc target |
  	target := targetMethod asUnsignedInteger + cmNoCheckEntryOffset.
  	pc := cPIC asInteger + firstCPICCaseOffset.
  	"Since this is a fast test doing simple compares we don't need to care that some
  	cases have nonsense addresses in there. Just zip on through"
+ 	1 to: maxCPICCases do:
- 	1 to: cPIC cPICNumCases do:
  		[:i|
  		target = (backEnd jumpLongTargetBeforeFollowingAddress: pc) ifTrue:
  			[^true].
  		pc := pc + cPICCaseSize].
  	^false!



More information about the Vm-dev mailing list