Smalltalk › Gnu

How does GNU Smalltalk build primitive selectors?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

mbratch

How does GNU Smalltalk build primitive selectors?

Hello

I started chasing down the issue with the display (`printOn`) for floats which led me to a few different issues. One in particular leads to a potential issue with the SmallInteger >> * operator primitive. However, I’m having trouble understanding how this is actually implemented and built, or how GNU Smalltalk in general handles primitives.

The SmallInteger >> * selector in kernel/SmallInt.st seems to get bypassed. I found VMpr_SmallInteger_times in libgst/prims.inl, but this doesn’t seem to get called, either (at least not as evidenced by trying to trace execution).

So I’m looking for a little guidance on the structure of this part of the code structure.

Thank you!

Sent from Mail for Windows 10

Paolo Bonzini-2

Re: How does GNU Smalltalk build primitive selectors?

Hi, some primitives are special cased and implemented directly in the byte
code interpreter. You can find the implementation in vm.def.

The primitives in prims.def will still be used with #perform:, for example
"2 perform: #* with: 3" will invoke the VMpr_SmallInteger_times primitive
in accord with the source code of the * method of SmallInteger.

Paolo

Il sab 20 feb 2021, 00:42 Mark Bratcher <[hidden email]> ha scritto:

> Hello
>
>
>
> I started chasing down the issue with the display (`printOn`) for floats
> which led me to a few different issues. One in particular leads to a
> potential issue with the SmallInteger >> * operator primitive. However, I’m
> having trouble understanding how this is actually implemented and built, or
> how GNU Smalltalk in general handles primitives.
>
>
>
> The SmallInteger >> * selector in kernel/SmallInt.st seems to get
> bypassed. I found VMpr_SmallInteger_times in libgst/prims.inl, but this
> doesn’t seem to get called, either (at least not as evidenced by trying to
> trace execution).
>
>
>
> So I’m looking for a little guidance on the structure of this part of the
> code structure.
>
>
>
> Thank you!
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>

mbratch

RE: How does GNU Smalltalk build primitive selectors?

Thank you, Paolo. I’ll paw through some of that stuff and see what I can figure out.

I think there may be an issue with the small integer multiplication in particular. It doesn’t seem to promote results to LargeInteger properly if at all when the product of two SmallInteger types overflows. I don’t know if “auto-promotion” is expected in Smalltalk arithmetic in general, but it does seem that certain other methods, such as conversion of floats to strings, counts on it.

Sent from Mail for Windows 10

From: [hidden email]
Sent: Saturday, February 20, 2021 4:54 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: How does GNU Smalltalk build primitive selectors?

Hi, some primitives are special cased and implemented directly in the byte code interpreter. You can find the implementation in vm.def.

The primitives in prims.def will still be used with #perform:, for example "2 perform: #* with: 3" will invoke the VMpr_SmallInteger_times primitive in accord with the source code of the * method of SmallInteger.

Paolo

Il sab 20 feb 2021, 00:42 Mark Bratcher <[hidden email]> ha scritto:

Hello

I started chasing down the issue with the display (`printOn`) for floats which led me to a few different issues. One in particular leads to a potential issue with the SmallInteger >> * operator primitive. However, I’m having trouble understanding how this is actually implemented and built, or how GNU Smalltalk in general handles primitives.

The SmallInteger >> * selector in kernel/SmallInt.st seems to get bypassed. I found VMpr_SmallInteger_times in libgst/prims.inl, but this doesn’t seem to get called, either (at least not as evidenced by trying to trace execution).

So I’m looking for a little guidance on the structure of this part of the code structure.

Thank you!

Sent from Mail for Windows 10

mbratch

RE: How does GNU Smalltalk build primitive selectors?

In reply to this post by Paolo Bonzini-2

Is there a simple way in the source to coax it to skip a specific operator implementation in the interpreter and let the Smalltalk implementation under kernel take effect?

Sent from Mail for Windows 10

From: [hidden email]
Sent: Saturday, February 20, 2021 4:54 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: How does GNU Smalltalk build primitive selectors?

Hi, some primitives are special cased and implemented directly in the byte code interpreter. You can find the implementation in vm.def.

Paolo

Il sab 20 feb 2021, 00:42 Mark Bratcher <[hidden email]> ha scritto:

Hello

I started chasing down the issue with the display (`printOn`) for floats which led me to a few different issues. One in particular leads to a potential issue with the SmallInteger >> * operator primitive. However, I’m having trouble understanding how this is actually implemented and built, or how GNU Smalltalk in general handles primitives.

The SmallInteger >> * selector in kernel/SmallInt.st seems to get bypassed. I found VMpr_SmallInteger_times in libgst/prims.inl, but this doesn’t seem to get called, either (at least not as evidenced by trying to trace execution).

So I’m looking for a little guidance on the structure of this part of the code structure.

Thank you!

Sent from Mail for Windows 10