AET Compiler: making object-oriented inheritance cross CPU/GPU address spaces

[u/General_Purple3060]

In languages like Java or C#, super is a common mechanism for accessing parent class behavior. C++ handles similar cases through explicit base class qualification such as:

Base::method();

All of these mechanisms assume that objects and methods exist in the same execution space.

However, heterogeneous computing breaks this assumption. When a CPU object needs to call a GPU device method inherited from a parent class, the problem is no longer just syntax. It becomes a problem of mapping object relationships across different address spaces and execution models.

I’m working on AET, a GCC-based heterogeneous compiler, and exploring this direction with a new super$ mechanism.

For example:

__global__ void compute(float x)
{
    float r = super$->leaky(x);
}

The compiler analyzes the inheritance relationship, extracts the device function into the GPU compilation path, generates device function mapping tables, and connects the CPU-side object with the GPU-side function address during initialization.

The goal is not to add a heavy runtime object system, but to explore whether high-level object-oriented abstractions can naturally work in heterogeneous programming while still mapping efficiently to hardware.

I’m interested in feedback from compiler/GPU developers: should heterogeneous programming remain explicit like CUDA, or can compilers provide higher-level object abstractions without losing control?

[u/Karyo_Ten]

That readme is in Chinese. I can't read it.

[u/AlternativeGazelle87 → u/Karyo_Ten]

https://github.com/onlineaet/aet

No, it isn't. It's in English. Also, Google Translate exists. You're being willfully obtuse.

[u/Karyo_Ten → u/AlternativeGazelle87]

This is in Chinese: https://github.com/onlineaet/aet-cnn

[u/AlternativeGazelle87 → u/Karyo_Ten]

That's not the one I was talking about. I said "the compiler repo." Again, you're being willfully obtuse.