[Libre-soc-bugs] [Bug 981] Support PowerPC ABI in cavatools

[bugzilla-daemon at libre-soc.org]

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

--- Comment #20 from Dmitry Selyutin <ghostmansd at gmail.com> ---
On Python generation part. No idea why we'd want to generate the C Python
module, because we already have what we need in plain Python. No, calling C
method is not going to save us that many cycles, because we are already going
call C bindings (ctypes, check the committed code).

Next, on allocation. I don't know why you keep referring to wrapping malloc or
free in scope of system calls. These are _not_ system calls, and no sane person
ever implements these as system calls. I already told what should be wrapped:
mmap/munmap. For those who lived before the historical materialism, there's
sbrk (which almost nobody uses these days other than for kegacy reasons,
preferring to use MAP_ANON instead).

The last but not the least, on the investigation part. I wouldn't have been
able to complete this work without investigation and research. Obviously I had
to investigate cavatools code before commiting anything there; that's simply
how the code gets written. My conclusions for now are as follows:

1. cavatools would be a challenging choice for us. It is RISCV-centric in the
bad sense: it does not provide an opportunity to introduce other architectures
there other than by extensively modifying the code.
2. The code quality leaves much to be desired. The way the code is written
makes it look like a pet project, probably which it indeed is. Most of the code
is written ad-hoc. Even syscall numbers were hardcoded as plain numbers. I'm
not even speaking about the API part, lack of header guards, naming and style.
3. What can be taken are concepts and ideas. These are not invented by
cavatools, sorry, nothing new.

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