[Libre-soc-bugs] [Bug 980] Implement C-based Power ISA pseudocode compiler

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=980

--- Comment #122 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Dmitry Selyutin from comment #119)
> 28 commits since the last update. This was a tough journey!! The code can
> now be compiled successfully.

hooraay! that's brilliant

>  This is a valid C code. The most difficult
> commit was this:
> 
> https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;
> h=90c93ec3cf18b96a9e70464f2b549c9bace1bbe4
> 
> Believe it or not, this was done manually.

daaamn... :)


> pointer to it". I cannot stress how annoying and boring it was, 

sometimes i find it good to switch off if you know what i mean :)

> probably one
> of the most annoying tasks I ever did, but I decided that writing yet
> another parser would consume even more time.

ahh... yes :)

> This can be checked via the following incantation:
> 
> gcc -Os -Isrc/liboppc -Wall -Werror -Wextra test.c -c -o test.o
> 
> As you see I took extra measures to ensure we pass some stricter checks.
> 
> I'm planning to add src/liboppc/oppc.c autogeneration 

ah not to the repo, please, if that's the plan? (maybr misunderstding)
 no matter if it takes a long time,
the project's policy is never to add autogenerated output.
the one piece of work that violated that rule took up 20% of
available drive space and it is a permanent serious problem,
the repo is 50 times bigger than all others.

> so that it's compiled
> as oppc.o, and be done with the task. The actual implementation of 238 calls
> (this includes the implementation of SelectableInt-like semantics, filling
> all these defines, all functions we have in helpers and isafn, switching for
> FPSCR attributes and so on). Yes, this will be a damn lot of work; even all
> the prototypes and definities took 1K+ lines of manually written code. 

yep. welcome to 5 years development.

>Some
> functions can be generated as well, and I think this is the path we should
> follow, eventually discarding as many manually written helpers as we can.

yes. hm if consulted beforehand i would have said "don't do it" but
you needed the protos to test the output, ho hum it is what it is.
doing introspection of the modules would, retrospectively, perhaps
have been a better option? plus it would remove ongoing de-sync /
maintenance headaches when python functions change (or new ones added)
they're done now, and do the job.

> So, I'm planning to add src/liboppc/oppc.c autogeneration as part of the
> build

build script and makefiles yes but to repo no? am i understanding right?

> and be done with this task. 

i am veeery happy for that to happen, you've done a hell of a lot.

> I might probably agree to some smallish
> additions which hopefully won't be as annoying as that header above. I
> already feel this is well underestimated, considering the efforts, though.

no, enough is enough, further work requires a bigger budget

> I'd like to listen to your thoughts and ideas.

if you can outline what it would take to do a python-cffi wrapper
plus auto-introspection/generation of the c protos to ensure that
the python helpers.py is the "canonical" source, plus a hefty budget
with a bit extra for some unexpected things (which we know always
haoppens sigh) and chuck it onto 1211 or 1212 as appropriate, that'd
be fantastic.

correction: if you are *interested* to do that... :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.