3 ms·

Can anybody answer why the author wrote "indirect branches tend to show up in object oriented languages"? Given that branches are, well, just branches in any l

Can anybody answer why the author wrote "indirect branches tend to show up in object oriented languages"? Given that branches are, well, just branches in any language, what makes OO so special? Also further down the author states "while FP registers have to be wider to handle vector execution" Again I'm pretty certain FP registers are larger owing to the greater precision they have, not specifically because they're designed for vector ops... please somebody explain why my understanding is wrong?

hayley-patton 3y ago
> Given that branches are, well, just branches in any language, what makes OO so special? In principle you have calls to whatever method associated with a given object, which are indirect as there is not one statically-known target of the call, but in practise you can optimise a lot out <https://youtu.be/9epgZ-e6DUU?t=2543 https://youtu.be/9epgZ-e6DUU?t=2543>.
NovemberWhiskey 3y ago
>Given that branches are, well, just branches in any language, what makes OO so special? I suppose the assumption is that you get lots of virtual functions.
dwaite 3y ago
> Can anybody answer why the author wrote "indirect branches tend to show up in object oriented languages"? While useful for function pointers and jump tables, I suspect they are speaking to polymorphism and vtables/witness tables.
kevingadd 3y ago
Indirect branches are different from regular branches. A regular branch is 'goto label', while an indirect branch is like calling a function pointer or calling a virtual method
jchw 3y ago
> Given that branches are, well, just branches in any language, what makes OO so special? Indirect branches. This is a result of vtable indirections. You are much more likely to encounter vtables in an object oriented language. Obviously, you can still have the same basic thing in a C program, e.g. SDL RWops, but in C++ for example, it's going to show up all over the place.
llm_nerd 3y ago
Virtual functions yield a lot of indirect branches. Virtual functions are a foundational part of object oriented designs. FP registers have gotten much larger than the normal types that people store. e.g. 128, 256, 512-bit registers. A normal double floating point (pretty much the largest normally used floating point representation) occupies 64-bits, while a normal int64 occupies, unsurprisingly, the same 64-bits. But we're getting the mega registers specifically because there are a lot of multiple-four-singles at once, and so on, SIMD functions.
monocasa 3y ago
> Also further down the author states "while FP registers have to be wider to handle vector execution" > Again I'm pretty certain FP registers are larger owing to the greater precision they have, not specifically because they're designed for vector ops... please somebody explain why my understanding is wrong? ARM Neon is both 128bit SIMD and the FPU for the system. There's not a separate FPU from the SIMD.
fulafel 3y ago
Indirect branches are common in many OO languages because calling object.method(arg) essentially does object.class.method(object, arg) or object.prototype.method(object, arg) - the address of method is loaded indirectly through the object's "class" field as it may be inherited or not. (In some cases the compiler may statically know the class of an object, if it's not allowing for subclassing and a potentially overridden method)

hayley-patton 3y ago

> Given that branches are, well, just branches in any language, what makes OO so special? In principle you have calls to whatever method associated with a given object, which are indirect as there is not one statically-known target of the call, but in practise you can optimise a lot out <https://youtu.be/9epgZ-e6DUU?t=2543 https://youtu.be/9epgZ-e6DUU?t=2543>.

NovemberWhiskey 3y ago

>Given that branches are, well, just branches in any language, what makes OO so special? I suppose the assumption is that you get lots of virtual functions.

dwaite 3y ago

> Can anybody answer why the author wrote "indirect branches tend to show up in object oriented languages"? While useful for function pointers and jump tables, I suspect they are speaking to polymorphism and vtables/witness tables.

kevingadd 3y ago

Indirect branches are different from regular branches. A regular branch is 'goto label', while an indirect branch is like calling a function pointer or calling a virtual method

jchw 3y ago

> Given that branches are, well, just branches in any language, what makes OO so special? Indirect branches. This is a result of vtable indirections. You are much more likely to encounter vtables in an object oriented language. Obviously, you can still have the same basic thing in a C program, e.g. SDL RWops, but in C++ for example, it's going to show up all over the place.

llm_nerd 3y ago

Virtual functions yield a lot of indirect branches. Virtual functions are a foundational part of object oriented designs. FP registers have gotten much larger than the normal types that people store. e.g. 128, 256, 512-bit registers. A normal double floating point (pretty much the largest normally used floating point representation) occupies 64-bits, while a normal int64 occupies, unsurprisingly, the same 64-bits. But we're getting the mega registers specifically because there are a lot of multiple-four-singles at once, and so on, SIMD functions.

monocasa 3y ago

> Also further down the author states "while FP registers have to be wider to handle vector execution" > Again I'm pretty certain FP registers are larger owing to the greater precision they have, not specifically because they're designed for vector ops... please somebody explain why my understanding is wrong? ARM Neon is both 128bit SIMD and the FPU for the system. There's not a separate FPU from the SIMD.

fulafel 3y ago

Indirect branches are common in many OO languages because calling object.method(arg) essentially does object.class.method(object, arg) or object.prototype.method(object, arg) - the address of method is loaded indirectly through the object's "class" field as it may be inherited or not. (In some cases the compiler may statically know the class of an object, if it's not allowing for subclassing and a potentially overridden method)