Forums

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

The struct/union assignment will definitely ease a few porting woes...

haroldoop wrote

The struct/union assignment will definitely ease a few porting woes...

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.

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.

PkK wrote

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.

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.

Calindro wrote

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.

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

PkK wrote

Calindro wrote

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.

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

Having the full label names in the .map file without further action to be taken would be great and all that is needed. :)

Calindro wrote

Having the full label names in the .map file without further action to be taken would be great and all that is needed. :)

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

Author	Message
PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	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

haroldoop Joined: 25 Feb 2006 Posts: 874 Location: Belo Horizonte, MG, Brazil	Posted: Mon Apr 08, 2019 11:55 pm
	The struct/union assignment will definitely ease a few porting woes...

PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	Posted: Tue Apr 09, 2019 5:16 am
	haroldoop wrote The struct/union assignment will definitely ease a few porting woes... 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.

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Sat Jun 08, 2019 9:43 am
Calindro Joined: 14 Apr 2013 Posts: 624	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.

NeonMan Joined: 24 Sep 2013 Posts: 141	Posted: Tue Jun 11, 2019 7:02 am
NeonMan Joined: 24 Sep 2013 Posts: 141	PkK wrote 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. 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.

PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	Posted: Wed Jun 12, 2019 11:55 am
	Calindro wrote 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. 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

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Wed Jun 12, 2019 12:06 pm
Calindro Joined: 14 Apr 2013 Posts: 624	PkK wrote Calindro wrote 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. 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 Having the full label names in the .map file without further action to be taken would be great and all that is needed. :)

PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	Posted: Wed Jun 12, 2019 1:19 pm
	Calindro wrote Having the full label names in the .map file without further action to be taken would be great and all that is needed. :) 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

Forums

View topic - SDCC 3.9.0 RC1