Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cbuilder: second half of cgen #24432

Merged
merged 8 commits into from
Nov 14, 2024
Merged

cbuilder: second half of cgen #24432

merged 8 commits into from
Nov 14, 2024

Conversation

metagn
Copy link
Collaborator

@metagn metagn commented Nov 14, 2024

Follows up #24423, needed more refactoring than I expected, sorry for ugly diff.

With this pretty much all of the raw C code generating parts of the codegen are abstracted into the cbuilder API (to my knowledge at least). The current design of NIFC does not implement everything the codegen generates, such things have mostly not been adapted, they are the following along with how I'm guessing they could be implemented:

  • C++ specific codegen: Maybe a dialect of NIFC for generating C++?
  • codegenDecl pragma: Could be passed as a pragma to NIFC
  • C macros, currently only used for line info IIRC i.e. nimln_(123): Just inline them when generating NIFC
  • Other C defines & #line: Maybe as NIFC directives or line infos?
    • There is also this #ifndef when generating headers but NIFC shouldn't need it
  • alignof/offsetof: Is in cbuilder but not implemented in NIFC, should be easy Edit: Done nifc: add alignof & offsetof, make sizeof only take type nif#120

For now we can disable C++ and the codegenDecl pragma when generating NIFC but since cbuilder is mostly designed to generate NIFC as a flag when booting the compiler, this hinders the ability to run the CI against NIFC. Maybe we could also make cbuilder able to generate both C and NIFC at runtime, this would be a large refactor but wouldn't be too difficult.

Other missing abstractions before being able to generate NIFC are:

  • Primitive types and symbols i.e. int, void*, NI, NIM_NULL are currently still constant string literals, NU8, NU16 etc are also sometimes generated like "NU" & $bits.
  • NIFC identifiers, i.e. adding .c to imported symbols and properly mangling generated ones. Not sure how difficult this is going to be.

@metagn metagn changed the title cbuilder: cgen part 2 cbuilder: second half of cgen Nov 14, 2024
@metagn metagn marked this pull request as ready for review November 14, 2024 14:31
@Araq Araq merged commit 726195d into nim-lang:devel Nov 14, 2024
18 checks passed
Copy link
Contributor

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from 726195d

Hint: mm: orc; opt: speed; options: -d:release
177688 lines; 8.841s; 653.395MiB peakmem

Araq pushed a commit that referenced this pull request Nov 15, 2024
fixes #24434

In #24432

```nim
let ex = "NIM_EXTERNC N_NIMCALL(void, nimLoadProcs$1)(void) {$2}$N$N" %
        [(i.ord - '0'.ord).rope, extract(el)]
```

```nim
procs.addDeclWithVisibility(ExternC):
   procs.addProcHeader(ccNimCall, "nimLoadProcs" & $(i.ord - '0'.ord), "void", cProcParams())
```

extern "C" makes a function-name in C++ have C linkage; it should be
effaced with C compiler
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants