It looks like enough functionality landed in the PPCI to warrant a new release. (Which is always a chance to announce it and spread a word about the project).

And IMHO, relocatable ELF is pretty big feature to warrant 0.6 version number.

In order to implement dynamic allocated str (#91) and more, today I worked on bringing malloc support. I am almost there (I altered the necessary python code for that), the only thing remaining is sbrk function, following this implementation I would need to link the information about the end of the free memory on the host. What would be the best way of doing that?

This PR (related to #113) has some works on the C compiler side to enable heap allocations on *nix systems (depends on brk syscall). Also some additions to the librt/libc parts.

My understanding that C frontend currently doesn't have inline asm support. Which means that any asm must be in a separate source, which means that currently it's not possible to compile a single C source and get an executable with one command. Rounded up to "integer digits" that in turn means "PPCI doesn't really work".

I'd humbly suggest that a race to get following scenario work (ppci-cc hello.c -o hello; ./hello) should be the first task for the project.

And for that, apparently inline asm support is needed. Per https://github.com/windelbouwman/ppci-mirror/issues/23, it should be implemented in GCC-compatible manner, which of course likely will take time and effort.

As a stop-gap measure, might just introduce adhoc __ppci_asm("mov rax, rdi") to get that syscall() func up and running. (With a social contract that __ppci_asm will be removed once normal asm is implemented, to keep the codebase clean).

Hi, I am not a system programmer so I have really limited skills on this subject, specially when comes to assembly. I am trying to make x86_64 musl longjmp work on ppci, this is the implementation:

.global longjmp
longjmp:
	xor %eax,%eax
	cmp $1,%esi             /* CF = val ? 0 : 1 */
	adc %esi,%eax           /* eax = val + !val */
	mov (%rdi),%rbx         /* rdi is the jmp_buf, restore regs from it */
	mov 8(%rdi),%rbp
	mov 16(%rdi),%r12
	mov 24(%rdi),%r13
	mov 32(%rdi),%r14
	mov 40(%rdi),%r15
	mov 48(%rdi),%rsp
	jmp *56(%rdi)           /* goto saved address without altering rsp */

Is there a guide to the asm that ppci reads? I know some things, but from simple examples. The above snippet should be something like the following:

global longjmp
longjmp:
	xor eax,eax
	cmp #1,esi             ; CF = val ? 0 : 1
	adc esi,eax           ; eax = val + !val
	mov (rdi),rbx         ; rdi is the jmp_buf, restore regs from it
	mov 8(rdi),rbp
	mov 16(rdi),r12
	mov 24(rdi),r13
	mov 32(rdi),r14
	mov 40(rdi),r15
	mov 48(rdi),rsp
	jmp *56(rdi)           ; goto saved address without altering rsp

And a linker script. Made possible by the inline assembly support, added recently.

The sample still has to perform various workarounds of PPCI warts, which rather be fixed before merging this sample.

Referring to greentreesnakes, constants have changed in handling from 3.8 and on. This PR attempts to unify the two and keep compatibility - with the current feature set.

The short of it is that ast.Constant exists in 3.6 but is not emitted until 3.8. This means that in 3.6 and 3.7 that strings/numbers generate Num/Str, whereas in 3.8, ast.Constant is used for both but differentiates by way of a Python object .value.

For me, Python 3.7 was previously hanging on ppci.common.CompilerError: ('Cannot do <_ast.Str object at 0x1029e8a10>', (mandelbrot.py, 31, 10)) before this PR, and works successfully after. Looks like it's not covered in the test suite currently.

With the following declarations:

struct S1 { int a; int b; };

struct S2 { int a; int b; union { int c; int d; }; struct S1 s; };

struct S2 v = {1, 2, 3, {4, 5}};

v.a is 1, v.b is 2, v.c and v.d are 3, but v.s.a and v.s.b contains garbage.

When compiling the following C code with "ppci-cc -O 2 xxx.c", an unexpected error is reported void g(int n);

void f() { int i; g(i); } Here is the progress report : 2020-01-15 22:59:12,590 | INFO | root | ppci 0.5.7 on CPython 3.6.9 2020-01-15 22:59:12,601 | INFO | cbuilder | Starting C compilation (c99) 2020-01-15 22:59:12,607 | INFO | cparser | Parsing finished 2020-01-15 22:59:12,610 | INFO | ccodegen | Finished IR-code generation 2020-01-15 22:59:12,612 | INFO | optimize | Optimizing module main level 2 2020-01-15 22:59:12,614 | ERROR | root | und_i_alloc = undefined is used 2020-01-15 22:59:12,614 | ERROR | root | None und_i_alloc = undefined is used I dig a bit and saw that the problem is reported by the IR verifier in irutils.py. It reports that instruction "undefined" has been found in the module. The instruction is apparently inserted by the "mem2reg promotor" during the optmizer pass. This is why the problem does not occur when compiling with -O 0. Note that if variable "i" is assigned a value before calling "g", the problem does not happen. If this comes from this, it should be reported in a clearer way.

It looks like PPCI requires Python3, which is great. It looks like "python -m ppci" syntax is used somewhere in the docs (as suggested in https://github.com/windelbouwman/ppci-mirror/issues/11), which is also great: https://ppci.readthedocs.io/en/latest/reference/lang/java.html#compile-java-ahead-of-time

However, that uses exactly python, and for most users nowadays that will lead to stack trace ending with:

AssertionError: Needs to be run in python version 3.x

Not exactly user friendly (especially for people not familiar with Python, and #11 suggests to keep those in mind).

So, suggested to use python3 consistently in the commands everywhere.

I personally would prefer to not rely on entrypoints created by the installer script (and ideally/eventually, not rely on the need for ppci to be "installed" at all).

So, the first thing I'm greeted is:

$ python3 -m ppci
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/mnt/hdd/projects-3rdparty/Python/Python-compilers-for-non-python/ppci-mirror/ppci/__main__.py", line 18, in <module>
    main()
  File "/mnt/hdd/projects-3rdparty/Python/Python-compilers-for-non-python/ppci-mirror/ppci/__main__.py", line 10, in main
    subcommand = sys.argv[1]
IndexError: list index out of range

Now, there's ppci-ld, but:

$ python3 -m ppci ld
...
ModuleNotFoundError: No module named 'ppci.cli.ld'

Suddenly, the linker is under python3 -m ppci link. Let's fix it up and make it consistent, which is of course "ld", per https://github.com/windelbouwman/ppci-mirror/issues/23 . If there's strong desire "link" can stay as an alias, but I'd recommend against it, let's just just clean up such small cases, it's just not worse to maintain "diversification" in such small things, it will only lead to confusion and maintenance overheads.

There are small typos in:

• ppci/arch/data_instructions.py
• ppci/arch/runtime.py
• ppci/lang/c/semantics.py
• ppci/wasm/components.py

Fixes:

• Should read support rather than supprt.
• Should read referred rather than refered.
• Should read necessarily rather than nessecarily.

Semi-automated pull request generated by https://github.com/timgates42/meticulous/blob/master/docs/NOTE.md

#if (1 ? -2 : 1u) < 0
#error
#endif

File : "<source>"
    1:#if (1 ? -2 : 0 + 1u) < 0
    2:#error
       ^ 
2022-04-24 21:27:27,454 |     INFO |       root | ppci 0.5.5 compiler on CPython 3.8.10 on Linux-5.13.0-1021-aws-x86_64-with-glibc2.29
2022-04-24 21:27:27,457 |     INFO |   cbuilder | Starting C compilation (c99)
2022-04-24 21:27:27,458 |    ERROR |       root | 
2022-04-24 21:27:27,458 |    ERROR |       root | (<source>, 2, 2)
Compiler returned: 1

ppci 0.5.5

Hi, I tried to load an existing WASM module (maybe a bit unusual module, I don't know).

<ipython-input-5-a1926f0a6fca> in <module>
----> 1 wasm.Module(open(r'/home/ekarni/pyodide/addlibs/__loader.wasm','rb'))

~/.pyenv/versions/3.9.6/lib/python3.9/site-packages/ppci/wasm/components.py in __init__(self, *input)
    109             elif hasattr(arg, "read"):
    110                 assert not hasattr(arg, "read_module")
--> 111                 return self._from_file(arg)
    112
    113         # Else, more direct instantiation

~/.pyenv/versions/3.9.6/lib/python3.9/site-packages/ppci/wasm/components.py in _from_file(self, f)
    248
    249         reader = BinaryFileReader(f)
--> 250         reader.read_module(self)
    251
    252     def to_string(self):

~/.pyenv/versions/3.9.6/lib/python3.9/site-packages/ppci/wasm/binary/reader.py in read_module(self, module)
     58             section_data = self.read_length_prefixed_bytes()
     59             with self.push_data(section_data):
---> 60                 self.read_section(section_id)
     61
     62         logger.info(

~/.pyenv/versions/3.9.6/lib/python3.9/site-packages/ppci/wasm/binary/reader.py in read_section(self, section_id)
     69     def read_section(self, section_id):
     70         """ Process a single section. """
---> 71         section_name = self._section_id_to_name[section_id]
     72         logger.debug("Loading %s section", section_name)
     73

KeyError: 12

A very simple module does work. This module was compiled by emcc. I can upload it.

…labels.

LLVM IR has a habbit of using implicit names in various places, from function params to basic block labels. In such cases, an autogenerated "numbered name" is used.

Signed-off-by: Paul Sokolovsky [email protected]

A while ago I've found a simple gc to use on a simple LISP implementation to be compiled with ppci-cc. What is lacking on master is __builtin_frame_address(0) and set/longjmp. Do you think this gc would be an interesting example to place inside tools? I have fixes for these two (x86_64). Instead of using a builtin __builtin_frame_address, I've made changes in the inline asm to allow something like this:

long ret;
asm("mov %0, rbp": "=r"(ret) ::);
void *tos = (void*) ret;