Re: [Sdcc-user] PIC18F4550 Extended instruction set

[Raphael N. <rn...@we...>]

Hi,

> What does it mean, extended instruction set? Extended compared to what,
> PIC16?

Extended instruction set refers to additions and changes made to the
interpretation of certain opcodes.

According to the 4550 datasheet, Sect. 26-2, 8 instructions have been
added (ADDFSR, ADDULNK, CALLW, MOVSF, MOVSS, PUSHL, SUBFSR, and SUBULNK)
to reduce the function call overhead.

The most important change, however, and the one causing incompatibility
with SDCC, is the changed interpretation of addressing modes:

    When the extended set is disabled, addresses embedded
    in opcodes are treated as literal memory locations:
    either as a location in the Access Bank (.a. = 0) or in a
    GPR bank designated by the BSR (.a. = 1). When the
    extended instruction set is enabled and .a. = 0,
    however, a file register argument of 5Fh or less is
    interpreted as an offset from the pointer value in FSR2
    and not as a literal address. For practical purposes, this
    means that all instructions that use the Access RAM bit
    as an argument . that is, all byte-oriented and bitoriented
    instructions, or almost half of the core PIC18
    instructions . may behave differently when the
    extended instruction set is enabled. [datasheet, 26.2.3]

As SDCC makes heavy use of the access bank, many memory accesses are
changed to be offset by FSR2 (which is used as frame pointer). As a
consequence, unexpected memory locations are being accessed, which
usually yields ... interesting results ;-)

> Does 18F4550 have extended instruction set?

Yes, the 2450/2550/4450/4550 family implementes the extended instruction set,
but SDCC cannot make use of it (and probably won't for a looong time, as this
would require quite fundamental changes to the code generator).

> Do I need to disable the extended instructions set?

Since SDCC r5276 (2008-11-25), the extended instruction set is
automatically disabled by SDCC by meddling with the user-provided
CONFIG4L byte (if no CONFIG4L byte is specified, Microchip states
that XINST defaults to being disabled, so we are lucky).
Prior to SDCC r5276, one had to explicitly state
  static __code char __at(_CONFIG4L) _conf4l = something & _XINST_OFF;
and if you missed _XINST_OFF, your program was bound to fail in
various interesting ways, the cause of which was rather hard to find.

> Is the SDCC support for PIC 18 series basically just an artefact of the
> support for PIC 16 series or does the compiler take advatage of the
> supposedly more C friendly architecture of the 18 series?

The code generators for 14-bit PICs (e.g., 16f*) and 16-bit PICs (18f*)
are separate, even though they share many ideas. The PIC16 backend
however makes use of the more advanced addressing modes (e.g., for WREG)
and the better stack management instructions of the 16-bit PICs.

However, SDCC does not support the newest addition (extended instruction
set) which is intended especially to support high level programming (i.e.,
C). USing these instructions would allow for more compact and more efficient
code (no more save/restore of r0x00?? around functions); I simply do not
find the time to rewrite the backend.

> While I'm an old hand in microcontrollers and C I'm new to PIC and SDCC
> so I would appreciate any insight on these matters.

I hope to have clarified the matter sufficiently. If not, feel free to ask
again.

Best regards,
Raphael