What EmbLinkRTOS needs from EmbCC (tracking)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start with the linked RTOS evidence, especially docs/engineering/hil-esp32-port-2026-11-05.md, docs/engineering/embcc-native-linux.md, and the named kernel paths. The checklist spans compiler builtins, host support, build integration, several architectures, and language conformance; first identify one item to split into its own issue, then verify its current status and define a focused completion criterion. The inventory alone does not specify a bounded change or test for the full tracking issue.
Written by the indexing model from the issue text.
Description
This tracks what EmbLinkRTOS still needs from EmbCC. It is an inventory of the RTOS repository as of f76cc7c (2026-11-08). The RTOS's CI pins EmbCC 0.0.1-beta. Each item gives the evidence on the RTOS side and the workaround the RTOS uses today. Items can be split into their own issues when work starts.
RTOS links below are relative to https://github.com/EmbLinkOs/EmbLinkRTOS/blob/f76cc7c/.
1. Xtensa code speed
The only EmbCC runtime measurements are on the ESP32. The same kernel and port built by EmbCC take about 1.8 times GCC's cycles.
Checked build, 40 MHz, in cycles (docs/engineering/hil-esp32-port-2026-11-05.md):
| EmbCC | GCC | Clang | |
|---|---|---|---|
| notification hand-over | 2090 | 1163 | 1325 |
| semaphore hand-over | 2075 | 1154 | 1250 |
| semaphore give + take | 436 | 226 | 218 |
| interrupt wake | 4211 | 2500 | 2697 |
Release build, 160 MHz, against FreeRTOS on the same board (docs/engineering/bench-esp32-freertos-2026-11-06.md):
| FreeRTOS (GCC) | EmbLink GCC 16.1 | EmbLink Clang 22.1.4 | EmbLink EmbCC | |
|---|---|---|---|---|
notify_handover |
1535 | 969 | 1135 | 1749 |
sem_handover |
1959 | 973 | 1056 | 1742 |
sem_give_take |
316 | 208 | 200 | 406 |
isr_wake |
3201 | 1951 | 2105 | 3247 |
Micro-costs under EmbCC: emb_thread_yield() with nothing to switch to costs 196 cycles; a software-interrupt round trip costs 318 (docs/ports/xtensa.md).
- Compare EmbCC's and GCC's code for the scheduler (
kernel/sched/sched.c) and the wait path (kernel/wait/wait.c), the hottest paths in these numbers.
2. Builtins the RTOS's compiler layer would use
include/emb/compiler/embcc.h defines none of the following, so the portable fallbacks in include/emb/compiler.h apply. If EmbCC already supports some of them, say which, and the RTOS will wire them in embcc.h (an RTOS change).
-
__builtin_clz,__builtin_ctz,__builtin_popcount. Without them, the scheduler's ready-set lookup (kernel/include/embk/word.h, called fromkernel/sched/sched.c) is a loop of up to 32 steps instead of one instruction. This may account for part of §1; it is not measured. -
__builtin_return_address(0). The crash record takes a software fault's pc from it (kernel/fault/fault.c), so under EmbCC that pc is 0. -
__builtin_constant_pand__builtin_unreachable. -
format(printf, …)checking,deprecated, and a C fallthrough attribute. Each is empty under EmbCC today.
3. Linux host compilation
EmbCC builds only the kernel on Linux. The RTOS's native port, board and tests are built by GCC, which also links: the "mixed" build of ADR-041 (docs/engineering/embcc-native-linux.md). That is the only EmbCC leg in the RTOS's CI.
- pthreads in the
x86_64-linux-gnuruntime. The error today isnative_port.c:20: error: cannot find include file "pthread.h". - Accept
__attribute__((__mode__)), so glibc's headers compile. glibc'ssys/types.h:164hastypedef int register_t __attribute__ ((__mode__ (__word__)));. - Ship a Linux
crt1.o. The 2026-10-14 snapshot failed withno crt1.o for x86_64-linux-gnu; check whether that is still the case.
4. Build-system integration
- CMake identification. CMake reports "The C compiler identification is unknown" and "Did not find file Compiler/-ASM", so it requests no dependency files. A stale 40 MHz tick configuration survived a rebuild because of it. The RTOS now forces
-MD -MT -MFitself (cmake/toolchains/embcc-depfile.cmake). An upstreamCompiler/EmbCC-*.cmakemodule, or a GCC-compatible identification, would fix this. - A dependency file for assembly sources. The RTOS adds
OBJECT_DEPENDSforxt_vectors.Sby hand (arch/xtensa/CMakeLists.txt).
5. Per architecture
Xtensa
- A release with
embld's Xtensa script support (D-024, #174). Until then, the ESP32 bring-up probe falls back to-Ttext/-Tdata. - A release with the working
embflash --esp(#173). The installed 0.0.1-beta build sent FLASH_END, the ROM answered error 0x06, and embflash exited 2. - Directives in Xtensa inline assembly. Only instructions are accepted, so
EMB_LAYOUT_MARKERuses a data form on__XTENSA__(ADR-054, A95). - Stop warning on unused
static inlinefunctions, as GCC and Clang do not. The RTOS marks three trace helpersEMB_UNUSEDfor it.
Together, the first two would let the RTOS add an EmbCC Xtensa CI leg.
AVR
-
.debug_frame: EmbDBG backtraces stop at frame 0. -
-gcode-size growth:-O0code may not fit the ATmega328P. - C++ on 16-bit targets ("the C++ lowering assumes a 32-bit int and 4-byte pointers").
There are no EmbCC size or speed numbers for AVR yet. Wiring __flash/progmem into the RTOS's flash macros and linking the conformance suite is a joint RTOS-side session (docs/ports/avr.md).
RISC-V
- Inline assembly:
lr/sc/amo*, thela/call/tailpseudo-instructions, and floating point. - The
interruptattribute. The RTOS uses an assembly trap entry.
Cortex-M
- CMSE with an FPU:
cmse_nonsecure_entryfunctions must clear the floating-point registers. - Armv6-M atomic helpers mask with PRIMASK, which has no effect in unprivileged Thread mode.
- Cortex-M23: checked only as an M33 with a Baseline instruction scan, never on an M23.
6. Language conformance and diagnostics
- Enforce
-std=(today accepted and ignored), so ISO conformance can be checked. - Refuse
_Thread_local/__threadon embedded targets, or implement it. Today each silently becomes one shared instance. -
__STDC_HOSTED__should be 0 under-ffreestanding; it is 1. - Complete
_Alignas, and_Atomicbeyond integer and pointer types. - The warnings the RTOS builds with:
-pedantic/-Wpedantic,-Wcast-align,-Wnull-dereference. Each is reported as "not a warning EmbCC has", 390 times across the RTOS's archived build logs. - Inline assembly: labels, wider-than-register outputs, callee-saved clobbers.
- Inlining of functions that return a struct. The RTOS's time constructors are macros for this reason (
include/emb/time.h, SPEC-001). The current toolchain profile no longer lists it, so it may be fixed; please confirm. - Build EmbCC warning-clean with GCC 14.2: a missing
readlinkdeclaration, then format-truncation and empty-body warnings.
Already done upstream
These need no work. The ten items of the RTOS's 2026-10-14 capability review are each done within their stated scope:
- Armv8-M stack limits;
- AVR linker scripts,
__flash/progmem, DWARF 4 and the EmbDBG register layout; - small RV32/AVR atomics;
- soft-float CMSE;
- Cortex-M23;
- SVD clusters/arrays/JSON;
- C++ without exceptions.
Constructor priorities, typedef alignment and 8-byte atomic helpers are also done.
The RTOS side still owes cleanup: some of its specifications describe these as missing, and its Xtensa default toolchain is EmbCC although its CI builds Xtensa only with GCC and Clang. That is being fixed there.
- Dominant language
- C
- Stars
- 1
- Forks
- 2
- Avg merge
- 20h 55m
- Merged PRs (30d)
- 73
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from EmbLinkOs/EmbCC
-
avr: errno does not link: __errno_location is not in the C libraryPossibly taken @Firat17aze claimed this today. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 50/100
Maintainers usually reply within 1 day
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
SPIDevice selects an active-high device as soon as it is createdPossibly taken @mikeysklar claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
adafruit/circuitpython#11869 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
gnif/LookingGlass#1352 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100