PCW compiler typedef'ed array issue

RF_Developer · Joined: 07 Feb 2011 Posts: 839

I'm a experienced professional developer working on PCWH 4.017 for a medium term contract. The company currently doesn't have support for the IDE or compiler.

I want to know if this is a known problem. If so, does anyone know if it has been fixed. In other words is it worth my while trying to make a case for re-establishing support?

The problem is a compiler issue relating to typedef and arrays. The generated assembler code for arrays of ints and int32s is different when directly declared from that when declared through an equivalent typedef. If declared with a typedef the compiler generates code that treats each int or int32 as if they were int16, however it correctly addresses the ints or int32s! Note that when single variables are used instead of arrays the code is good.

Here is my test code. If the declare, which defines the type to test, is int8 or int32 then the problem occurs, however int16 is OK.

I am targeting the PIC18F8585 at 10MHz.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I copied and pasted your code into an MPLAB project and compiled it with
PCH vs. 4.118. Here's the .LST file:

Ttelmah · Joined: 11 Mar 2010 Posts: 19369

And, the critical thing is the PCWH version here. Generally, the early V4 compilers, _were not useable_. The 'line' for a compiler that began to work reasonably well, was around the late 4.06x version. 4.017, I wouldn't even trust to compile a basic 'hello world' type program, let alone deal with typedef and an array. I keep the compilers I use for projects, and there is a large 'gap' in the sequence, going 3.249, then 4.070....
Just as a test, I stuck the typedefs into 4.099, and this too handled them OK.
Forget 4.017.
For many months, there was a sticky thread at the head of the forum, about the progress with the compilers. This was only removed, when they began to work.

Best Wishes

RF_Developer · Joined: 07 Feb 2011 Posts: 839

Thanks, that pretty much answers my questions, and raises possibly nasty issues.

For a long while yesterday I thought I was going out with the fairies... before finding this problem.

I've worked round it by simply removing the affected typedefs. Not so tidy, but at least it works!

The long term implications are more worrying. Yes, I can perhaps persuade the company to upgrade, but I also have to persuade them that they have to use a commercially available tool that for fairly long periods has been known to have had significant functional shortcomings (i.e. is potentially unusable cr&p)... but then what software tool doesn't in one way or another?

By the way, does anyone else find the debugger's - possible legacy hangover - habit of displaying pointers as 8 bit only rather annoying, and massively timewasting?

Oh yes, and our two Mach X programmer/debuggers are only borderline usable as their comms locks up in some unknown way; commonly in the verify pass after loading ICD code but also while actively debugging. The CCS IDE's handling of these errors is very frustrating, necessitating lots of waiting (generally accompanied by groans, sighs, cusses and copious cups of tea) and killing of the IDE app and other similar drastic measures. I typically lose two or more hours to this every day. So much so that I've had to insist that we change to another ICD unit, probably Microchip's own MPLAB ICD3 (we apparently use the ICD2 for our small-scale production programming).

Anyway, thanks for the replies.

RF_Developer