Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
barneypitt
@barneypitt
I'm really confused about what SYCL is doing here. Why would you want to go from java bytecode to SYCL?
CoreRasurae
@CoreRasurae
or ```Half a,b; a+=b;
@barneypitt That is just as an example that we may at some point want to generate code other languages rather than OpenCL only
*generate code to other languages...
instead of SYCL, could CUDA, or could be HSA
or nothing else for now
or OpenACC
who knows
@barneypitt if we have an AST like data than it is easier to support such use cases
if they arise
CoreRasurae
@CoreRasurae
but at least I think it is relevant
to have OpenCL 1.2 and 2.0
generators
as they are quite differente
and some devices are OpenCL 1.x only
and there will also be OpenCL Next
plus there is also Vulkan
and Metal on Mac
this vectorized programming technologies are getting quite fragmented
instead of joining forces to have a neat solution for everyone
Aparapi could be what Hibernate was for databases, or even better
CoreRasurae
@CoreRasurae
to avoid vendor lock-in
barneypitt
@barneypitt

Got to go soon. But to be clear, when you started talking about an AST I assumed you meant from source code. Which sounded great, but was not Aparapi. But I was unlear what "AST from bytecode" meant. To me, it means a hierarchical desciption of the bytecode, which is already what the Instruction class is.

But instruction is not a very friendly hierarchical description of the bytecode - doesn't really allow iteration/navigation. So if what we're talking about is a much-improved, more flexible, navigable successor to Instruction, then I wholeheartedly agree, bring it on!

CoreRasurae
@CoreRasurae
@barneypitt There are already implementations that do that
barneypitt
@barneypitt
And multiple backend support, obviously also cool.
Okay, cool, do you have links to those implementations? No point in us reinventing the wheel!
CoreRasurae
@CoreRasurae
@barneypitt https://asm.ow2.io/
there are many others
I haven't had the time to play with them
they aren't true AST, but rather AST like data
"The JVM Bytecode is parsed and transformed into an intermediate representation. This intermediate representation is passed thru optimizer stages and sent to a backend implementation for target code generation."
Referring to Bytecoder
we would need to assess which are good and which aren't
barneypitt
@barneypitt
Ah, I knew about ASM (not much), but hadn't thought of it as using an AST. But as you say, I suppose it's a sort-of-AST.
CoreRasurae
@CoreRasurae
yes, it isn't a true AST
barneypitt
@barneypitt
Any way, that's enough food for thought for one day, I need sleep! G'night.
CoreRasurae
@CoreRasurae
thanks! G'night for you too.
grfrost
@grfrost
I like ObjectWeb/ASM because it is already used by the JVM. So already installed. No extra jars.
grfrost
@grfrost
Bytecoder looks interesting. Although, it seems to duplicate Graal. Looks like it is based on the samd Cliff Click paper. ObjectWebAsm is already used by the JVM (to link method handles) since Java 7/8? So no new jars. I know I keep pushing Graal, but it solves all these things ;)
CoreRasurae
@CoreRasurae
@grfrost for me its ok, as long as we are confident that is a good choice for our purposes
CoreRasurae
@CoreRasurae
I have to go now
time to rest
see you
Jeffrey Phillips Freeman
@freemo
Going to work on windows compile again tomorrow btw, hit a lot of deadends last time but have some ideas now...
Jeffrey Phillips Freeman
@freemo
If there are no objections im just going to publish the release using the manual compile process. I still havent hacked out cross compile and dont want to hold up release
CoreRasurae
@CoreRasurae
@freemo for me is ok
Jeffrey Phillips Freeman
@freemo
I had to recover an old VM image of windows just to be able to compile it. Otherwise I'd have no way to even install windows
So you can imagine I'm not diggin that somultion
CoreRasurae
@CoreRasurae
@freemo I believe so, but as a temporary workaround...