[Vm-dev] VM Maker: VMMaker.oscog-eem.2675.mcz

[Eliot Miranda]

Hi Nicolas,

On Fri, Jan 24, 2020 at 1:06 PM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> Hi Eliot,
>
> Le ven. 24 janv. 2020 à 01:57, <commits at source.squeak.org> a écrit :
>
>>
>> Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
>> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2675.mcz
>>
>> ==================== Summary ====================
>>
>> Name: VMMaker.oscog-eem.2675
>> Author: eem
>> Time: 23 January 2020, 4:57:20.930803 pm
>> UUID: ac4a578f-84c7-491c-924d-ca554ddc19a9
>> Ancestors: VMMaker.oscog-eem.2674
>>
>> Cogit: Correct the definition of genPrimitiveHighBit.  If there is no
>> implementation of LZCNT then it should return UnimplementedPrimitive, not
>> CompletedPrimtiive.
>>
> +1
>
> Reverse the order of operands in ClzR:R:; this is a left-to-right
>> assembler, not an ATT syntax right-to-left one.
>>
> +1, case of brain failure to mimic existing operations...
> For some low level ops, it seems I would make an equally bright choice by
> flipping a coin ;)
>

Yes.  Thus was perhaps not my best choice.  Early on I was exposed to
left-to-right assemblers and found right-to-left assembler, such as that
for the ARM, distasteful.  Now that I've spent so much time with the ARMv8
I'm starting to change my mind.  But since we have what we have, we should
be consistent.  The most maddening thing for me is CmpR:R: CmpCq:R: et al.
I still can't understand which way is which and continually have to look at
examples to get it right.  Sigh...


Implement OrCq:R:R: to save an instruction in genPrimitiveHighBit.
>> Move genHighBitIn:ofSmallIntegerOopWithSingleTagBit: into the backEnd
>> where it belongs.
>
> +1,
> it probably ended here at the beginning of my iterations, then code
> generation is lax enough so I forgot
> it's always a problem to know where to put the slang code (since it does
> rarely use receiver)
>
> Nuke the useless
>> genHighBitAlternativeIn:ofSmallIntegerOopWithSingleTagBit:.
>>
> +/- 1 ?
> genHighBitAlternativeIn:ofSmallIntegerOopWithSingleTagBit: was for using
> the BSR instruction when there is no LZCNT
> Do you mean useless because those µproc are obsolete enough to not bother?
>

Oops!  I did not realize that's what it was for.  I only looked deep enough
to see that it answered zero and thought OK let's nuke it.  I apologize!
This would have been good to comment, as in "This is a place-holder for an
implementation that uses BSR when LZCNT is unavailable.".  I'll restore it
soon (but right now I've discovered that I *can* get around the memory
protections against self-modifying code in current linux, and in an elegant
way, and I have only hours before tomorrow's meet in Palo Alto, so I'm
under the gun :-) )


=============== Diff against VMMaker.oscog-eem.2674 ===============
>>
> [snip]

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200124/960535a5/attachment.html>