Date: Mon, 27 May 2013 13:12:56 +0200 (CEST)
From: "Maarten Brock" <firstname.lastname@example.org>
Subject: Re: [Sdcc-user] 8051 optimization question
SDCC does not perform this optimization unless you tell it to with
--acall-ajmp. This assumes that ALL lcall instructions can be replaced
with ACALL independent of their address (it happens at compile time). In
other words it assumes that everything is placed in the same 2kB. If your
device is limited to 2kB anyway then it is certainly worth it.
But a generic implementation would have to check that addresses lie in the
same 2kB block. This can only be done during/after linking. And then it
messes up the addresses so it needs to be done in iterations. The linker
would also need to understand the instructions which it currently does
And then there is the problem of handling jumptables which can come from
switch statements. They use a calculated address to jump into the table.
These are reasons why this is really difficult and thus not implemented.
If you have 2kB or less you can safely enable the option. If you have
more, we hope you can live with the larger instructions.
> We're happily using sdcc in a project of ours in which we're very close to
> the code space limits of our 8051 device.
> We've whipped up a script that consumes the .rst files produced during
> compilation to test whether lcall/ljmp intructions could be replaced by
> acall/ajmp, and have found many candidates for this size optimization.
> Does sdcc attempt to perform this kind of optimization? If not, would it
> be possible or interesting to add it?