Hi Tim,

declaring it as int is misidentifying it under 64 bits. I'd declare it as __aeabi_idivmod(long dividend, long divisor).

On Mon, Jul 13, 2015 at 4:53 PM, commits@source.squeak.org wrote:

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

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

Name: VMMaker.oscog-tpr.1414 Author: tpr Time: 13 July 2015, 4:52:46.377 pm UUID: cc8ee57d-fbf9-409f-93da-6a9d5442e435 Ancestors: VMMaker.oscog-tpr.1413

Final (please) change for ARM __aeabit_idivmod support. Benchmarks suggest a useful improvement as a result. Scratch PacMan on a Raspberry Pi2 runs at 30fps or so.

=============== Diff against VMMaker.oscog-tpr.1413 ===============

Item was changed: ----- Method: CogARMCompiler>>aeabiDivModFunctionAddr (in category 'ARM convenience instructions') ----- aeabiDivModFunctionAddr

• "return the address of the __aeabi_idivmod() call provided by the ARM

low level libs to do an integer divide that returns the quo in R0 and rem in R1.

• A word on the somewhat strange usage of idivmod herein; we need a

declaration for the _aeabi_idivmod helper function, despite the fact that in a simple C program test, you don't. To get that declaration we need a variable to hang it off and said variable needs to be referred to in order to not get culled. Thus the temp var idivmod, the declaration for it that has nothing to do with it and the odd usage in the inSmalltalk: block."

•   | idivmod |
  

• "return the address of the __aeabi_idivmod() call provided by the ARM

low level libs to do an integer divide that returns the quo in R0 and rem in R1" <returnTypeC: #usqInt>

•   <var: #idivmod declareC: 'extern void __aeabi_idivmod(int
  

dividend, int divisor)'>

•   ^self cCode: '(usqInt)__aeabi_idivmod' inSmalltalk:[idivmod :=
  

#aeabiDiv:Mod:]!

•   ^self cCode: '(usqInt)__aeabi_idivmod'
  

inSmalltalk:[#aeabiDiv:Mod:]!