|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
SDCC 3.9.0 RC1
Posted: Mon Apr 08, 2019 8:52 pm
|
Dear SDCC users,
Today the first Release Candidate (RC1) for SDCC 3.9.0 has been created. As always it has been put online in our SourceForge File section. https://sourceforge.net/projects/sdcc/files/ If you have the time, please verify it and report back with the positive or negative results. There have been various improvements, both features and bug fixes since SDCC 3.8.0. The full ChangeLog is at https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-3.9.0-pre1/sdcc/ChangeLo... The following is a list of particularly noticeable new features. * Support for struct / union assignment. * Optimizations in the stm8 backend relevant to soft float increase Whetstone score by two thirds. * Improvements in rematerialization in the stm8 backend improve code generation for struct, union and arrays. * New stack allocator reduces stack space usage for the stm8, z80, z180, gbz80, r2k, r3ka, tlcs90 backends. * New ez80_z80 backend for eZ80 in Z80 mode. * Removed deprecated sdcclib utility. * New pdk14 backend for Padauk µC with 14-bit wide program memory. * New in-development pdk15 backend for Padauk µC with 15-bit wide program memory. Philipp Klaus Krause SDCC 3.9.0 Release Manager |
|
|
Posted: Mon Apr 08, 2019 11:55 pm |
The struct/union assignment will definitely ease a few porting woes... | |
|
Posted: Tue Apr 09, 2019 5:16 am |
Unfotunately, we don't have passing and returning of struct / union yet, though. Philipp P.S.: There currently is a survey on use of various SDCC backends: https://terminplaner4.dfn.de/xudoK5vzYi3oIX6O If you would like to see support in SDCC for a device not yet supported or if you use the mcs51 backend for a device that has support for dual dptr, please state so (and which device it is) in a comment. |
|
|
Posted: Sat Jun 08, 2019 9:43 am |
Hi Philipp,
is there a way to raise the limit of symbol names in the map file? It currently seems to be limitted to 32 characters which can cause ambiguity if there are symbols that start with the same 32 characters. Besides that, it would be great to have the full names of these symbols when they are shown in a debugger. |
|
|
Posted: Tue Jun 11, 2019 7:02 am |
I've attempted to adapt sdcc z80 backend to emit Intel 8085/8080 code since both are very similar but quickly got lost. I have a dozen of 8085 laying around and wanted to use them for something useful. Just for the sake of it. |
|
|
Posted: Wed Jun 12, 2019 11:55 am |
There is separate debug output via the --debug option giving a .cdb file. Some other SDCC backends even support ELF/DWARF debug information. If users want this for z80, too, it could be ported. Philipp |
|
|
Posted: Wed Jun 12, 2019 12:06 pm |
Having the full label names in the .map file without further action to be taken would be great and all that is needed. :) |
|
|
Posted: Wed Jun 12, 2019 1:19 pm |
Unfortunately, I don't know a way to do that. The linker emits the .map file; the linker is forked from an older version of the asxxxx one. The long-term plan is to merge current asxxxx into the sdcc fork, so it might be unwise to introduce an additional difference at this point by supporting an extrawide .map format. Philipp |
|