experiments in panama code generation

[Michael Zucchi]

All,

For what it's worth i've published [1,2,3] the code generator i've been 
working on for the last few weeks (months? - i've spent way more time on 
it than i care to admit).  It's of course more work in progress than 
panama but maybe someone will find something of use, if nothing else the 
generated code has some examples of how to use the current apis.  The 
gcc plugin is also quite complete for extracting all available 
information that can then be used by other tools, although it's one hell 
of a mess of code at this point.

It contains some examples for a toy api (for prototyping), ffmpeg (plays 
video frames in a jframe), opencl (does some info queries), and vulkan 
(runs a compute shader and shows the result in a jframe).  They all use 
a common helper module (notzed.nativez) for various reasons i sort of 
don't like that but its hard to avoid.

The original cause was to do the stuff jextract wasn't ever going to - 
more selective and direct config-driven generation of java-friendly apis 
from c header files.  jextract can be more selective than it used to be 
when i started but the rest is much the same.  Apparently also bitfields?

Simple example of what i'm trying for:

class cl_h {
     public static int clEnqueueReadBuffer(
         Addressable command_queue,
         Addressable buffer,
         int blocking_read,
         long offset,
         long size,
         Addressable ptr,
         int num_events_in_wait_list,
         Addressable event_wait_list,
         Addressable event) { ... }
}

Weird class name, no type checking, must check return, must manage the 
wait list by hand.  Having to use MemoryAddress.NULL for nulls. To make 
a usable api for general consumption one has to write another class to 
call this one - but that either needs another complete c parser and 
generator, or a lot of manual labour.

vs

class CL {
         public static void clEnqueueReadBuffer(
             cl_command_queue command_queue,
             cl_mem buffer,
             int blocking_read,
             long offset,
             long size,
             MemoryAddress ptr,
             cl_event_list event_wait_list,
             cl_event_list event) { ... }
}

Simple class name, typed arguments, throws exception on error, the event 
list is managed/updated automatically, implied parameters don't need to 
be supplied, simple null for null.  This is direct output from a fairly 
simple config file [4].

Structures and unions are similar.   Classes are typed holders of 
MemorySegment and have normal java getters and setters, anything can be 
renamed to be more java-like, fields can be excluded if they're private 
or not useful, can be read/write and indexed acceess is optional.  It's 
quit a pity you can't implement Addressable as it would just be so much 
tidier than having to reimplement the same thing for the same purpose 
but in an incompatible way.

I suppose my aim is to keep working on it until it's complete enough and 
then create some specific libraries that use it.  A secondary aim will 
be to explore approaches/code-size/performance.  But how long that takes 
and what i do depends on where my interests take me.

Why?  Just for fun really, it's just a puzzle to solve.  I've taken a 
few years off working and i'm getting a bit bored of going for bicycle 
rides/drinking at the pub/reading books/gardening/playstation/cooking 
and i've got some long-standing jni projects to update to panama.

Cheers,
  !Z aka Michael

[1] 
https://code.zedzone.space/cvs?p=panamaz;a=blob_plain;f=README;hb=HEAD 
README
[2] https://code.zedzone.space/cvs?p=panamaz&a=tree Source tree browser.
[3] https://code.zedzone.space/git/panamaz git url
[4] 
https://code.zedzone.space/cvs?p=panamaz;a=blob_plain;f=src/notzed.clstatic/gen/opencl.api;hb=HEAD

||