On 01.04.22 17:11, Benedikt Freisen wrote:
The renaming was actually discussed rather extensively over the course
of about a year, albeit apparently only on the developer mailing list.
The actual renaming then took place in early December.
If you genuinely need the old target specific macros, you could use a
compatibility header via pre-inclusion, i.e. using e.g. "--include
gbz80_macros.h" or something like that and conditionally define gbz80
macros therein depending on sm83 macros.
Greetings,
Benedikt
Am 01.04.22 um 16:58 schrieb Tony Pavlov via Sdcc-user:
Hello Benedikt,
BF> Not only is sm83 the actual name of the CPU core in use, but
BF> additionally, multiple targets, including gbz80/sm83, got a new default
BF> calling convention with 4.2.0 that results in more efficient code.
Target name and calling conventions are VERY DIFFERENT, NOT CONNECTED THINGS.
You broke all define dependencies, etc. Just WHAT FOR?
Here is the thread:
https://sourceforge.net/p/sdcc/mailman/sdcc-devel/thread/1fff4548-3010-19b0-d9e1-01df9f391d1c%40spth.de/#msg37245798
I wouldn’t call it extensive. It started a year ago and came back half a
year ago after the calling convention changes.
I only had the command line options `-mgbz80` vs `-msm83` in sight. We
probably silently break peep hole rules, I don’t think it warns if the
`isPort` argument isn’t known.
But we definitely made it impossible to link against libraries built for
<4.2.0. Without the renaming one would just need to change the headers,
now it’s necessary to either recompile with sdcc 4.2.0 or to manually
change the rel files. It’s impossible to compile a library that can be
used with sdcc 4.1.0 and 4.2.0 without modifying the rel files. And this
I do regret retrospectively.
--
Freundliche Grüße / Yours sincerely
Sebastian „Baŝto“ Riedel
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
