avr: code is 1.6 to 1.8 times avr-gcc's size on EmbLinkRTOS's Uno images
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 50/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- c
- Bereich
- compilers, performance
Rechercherichtung
Compare EmbCC and avr-gcc output for the scheduler in kernel/sched/sched.c and wait path in kernel/wait/wait.c, using the same EmbLinkRTOS sources and -Os settings described in the issue. Start by checking the corresponding generated code and size measurements; completion means identifying where the size difference comes from and reporting whether those paths explain the reported AVR image growth.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
The first AVR size numbers for EmbCC, which #184 noted were missing. EmbCC 0.1.0 builds EmbLinkRTOS's Arduino Uno conformance images 1.6 to 1.8 times as large as avr-gcc does, so 12 of the 22 overflow the ATmega328P's 32 KB of flash.
Text plus data, in bytes, the same sources (EmbLinkRTOS 0f776b5, tiny profile, checked, crash record on), both at -Os:
| Image | avr-gcc 14.4.0 | EmbCC 0.1.0 | Ratio |
|---|---|---|---|
test_fault |
11,992 | 21,578 | 1.80 |
test_time |
17,592 | 30,472 | 1.73 |
test_irq |
16,866 | 27,730 | 1.64 |
test_sched |
16,432 | 26,734 | 1.63 |
The images that no longer fit overflow the text region by 356 to 7,948 bytes (test_thread's text ends at 0x9d0c against the region's end at 0x7e00).
Getting there needed two local changes, neither in EmbCC: a workaround for the lo8/hi8 symbol cut (filed separately), and the RTOS's AVR toolchain file naming EmbCC's embcc-ar and embcc-ranlib; with macOS's ar the archives held only a BSD symbol table, which embld reports as "too small to be an object". That second one is the RTOS's to fix.
A first look at what grows would compare the two compilers' code for the scheduler (kernel/sched/sched.c) and the wait path (kernel/wait/wait.c), as §1 of #184 asks for Xtensa.
Part of #184 (AVR).
- Vorherrschende Sprache
- C
- Sterne
- 1
- Forks
- 2
- Ø Merge
- 20 Std. 55 Min.
- Gemergte PRs (30 T.)
- 73
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus EmbLinkOs/EmbCC
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
documentation good first issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement good first issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement good first issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 83/100
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 55/100
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in EmbLinkOs/EmbCC
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 73/100
ChupathingyCE/chupathingyce#1020 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
-
enhancement good first issue
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 91/100
-
C:dataplane
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
yanet-platform/yanet2#3395 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Crash in mdns componentOffen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 75/100
openvehicles/Open-Vehicle-Monitoring-System-3#1575 ·
Maintainer antworten meist innerhalb von 4 Tagen