We've had a lot of problems that have been traced back to the Zilog compiler for eZ80 during the years.
Sure, our project is big, has many files, some of them pretty big - but they are all well formed and strictly typed.

We have not been able to compile our project with optimizations for the past 6 years because the optimizations simply break the compiled code in a variety of locations (in most cases, complete nonsense code is generated) but when 4.11.1 was released we were still happy, because that was the first compiler version that we could trust *without optimizations* and we have been using it ever since, but trying every new release to see if it works properly. Never does, at least not consistently.

When 5.1.1 was released, I did - as usual - try it out with and without optimizations and to my great joy it actually seemed to be working, even with optimizations turned on! I announced the great news and we danced, drank and celebrated... but alas, 'twas too soon.

I've been compiling releases with this version of the compiler since then, but recently I had to track down a strange bug and lo and behold - yet another deal breaker.

Again, our company looses a sizeable portion of income due to semi-broken Zilog tools.

Below is an extract from the assembly code generated with 4.11.1, our compiler of choice, and the 5.1.1 with optimizations.
The code produced by the 5.1.1 (left side) version is clearly not working, while the 4.11.1 (right side) is.



For reference, the macros are:



HIGH8 and LOW8 are macro references to the high/low bytes of a 16-bit word, others are 8-bit patterns - 0x80, 0x80, 0x40 in order of appearance.

Now, the code produced by the 4.11.1 compiler is a whole story in and of itself (simple boolean 8-bit operations being upconverted to 24-bit and checked agains zero by the insanely slow __icmpzero function) at least it works and later versions have fixed/"fixed" this problem. Since we are, again, stuck with this compiler we simply cannot move our products forward due to performance issues caused by these insane boolean operations that often has execution times of more than 40 times that of properly generated code - and yes I've done the math, and the benchmark, it's 40x.

The 5.1.1 compiler on the other hand - I have no clue what's going on there...

The data (link) is placed in the current functions stack frame at address IX-8 and -7 (16-bit) but when it is read back (for no reason, it's already available in BC and it's not volatile - i thought this was what optimizations should be doing) it is read from IX-28, -27 and -23.

What's interesting here is that it is not only incorrect, but the same referenced data is read from different addresses at different points (it's 16-bit, but has reads from three different locations) and hear this - the stack frame for this function is only 18 bytes which means that it's actually reading data from outside of the current stack frame - that is - data that the function has no knowledge or control over, or from the functions point of view - gibberish.

As if that weren't enough it fails to AND the data to produce the specified checks and basically translates back to:



where foo are all references to data that cannot (legally) be referenced by this function.

I swear on my mothers grave, to god and the great turtle that carries the earth that Zilog has not release a single stable, reliable and consistent compiler for at least eight years by now - I've used them for the past 6 years, and my colleagues have told me many similar stories of the even earlier ones.

But you are using the 4.11.1 one successfully you say? Yes, true! But it is, in addition to the 8-bit boolean performance issues mentioned above, plagued by random "Internal Compiler Error" issues, and when I say random I mean that simply hitting recompile over and over again eventually gives me a working file. That's consistency (and productivity) out the window.

Smaller projects mostly compile well, but I would be lying if I said I haven't seen bugs even in the most simple programs (we're talking a single file, less than 50 lines of code, compiled for the Zilog Ethernet module - nothing custom at all) so saying that this isn't a problem for the majority of users just isn't true - while it doesn't happen often it CAN happen any time and the compiler can as such simply not be trusted to produce correct code.

Another similar anecdote of historical interest was when an earlier version sometimes (like 1 in 3) translated



into assembly code equivalent to:



That is, at the eight and ninth copy it starts doing nonsense copies to and from the same location, while at the tenth copy reverts to normal behaviour. Mind-boggling. The support response was, as it always is for these kinds of more technical issues, "cannot reproduce".

For the love of all things sacred:

SCRAP ZDS II AND MOVE TO ECLIPSE!
REPLACE YOUR COMPILER TECHNOLOGY WITH A BACK-END FOR GCC, LLVM OR SIMILAR!

Or, at the very least - make your compiler open source so we can fix the bugs ourselves - we already know the code is bad, don't be ashamed of showing it to us. Whatever all of you executives may think there are no secrets in there, you do not have compiler technology you need to protect, there are many open source projects that have done things better and therefore no-one will have any reason to steal your IP any more than the broken 16" CRT TV that is gathering dust in my attic.

Please, I'm on my knees here and the mental health of our entire development force is on the verge of collapse.
We need working software, we needed it 5 years ago, things went critical a long time ago and has only been getting worse ever since.

I can fully understand the frustration of the OP. In our industry there's nothing worse than having to work with a broken compiler. In the past I did my share of finding bugs in compilers. There's always a lot of wasted time involved because first you have to exhaust the possibility of errors in your own code.

Unlike the OP's experience with Zilog here, when I was in a similar situation (a project where such problems would hit the bottom line directly), when I forwarded the results of my compiler analysis (much like those examples the OP posted), the company responsible for the compiler and the chief designer himself immediately handled it and I would get a fixed compiler in my hands, almost immediately. Every time. The later official compiler releases would then include the fix(es) in those compiler updates I had earlier received directly. Like Zilog, the vendor I worked with was a hardware vendor, they had a small subdivision responsible for producing compilers for their architecture. As soon as I had reported the first compiler problem they didn't hesitate putting me in direct contact with the compiler division, and I reported future problems directly to them. This efficient way of handling something as critical as compiler bugs was the direct cause for us being able to use and sell their hardware to customers for years after. Zilog has a job to do here, and it's in their own interest.

(I have a printout of one of my old hand-annotated machine code compiler output analysis sessions taped to a shelf near my screen, to remind me of what kind of intricate problems compiler bugs can cause. I found the old printout a couple of years back when I was digging through old storage boxes.)

-Tor

Thanks for sharing your experience!

I can't imagine anything more frustrating either, especially when you get no acknowledgement.
Most of the time it feels like talking to a brick wall.

I used to have a better contact at Zilog, but after reporting new bugs (in the network stack) virtually every day I guess the workload just got too big and I got cut off. Interesting decision when I was more or less doing their work for them, for free no less.

Everybody makes mistakes and I would certainly not mind a few bugs now and then if they, as you describe, are taken seriously and fixed quickly. With Zilog we have sometimes had to wait over a year for updated software and usually when a new major revision like that is made there is often more functionality broken than was fixed. Most of the cases though, promised fixes are nowhere to be seen and there no mention of them.

Promised may be to strong a strong though, I've never gotten anything beyond "we'll look into it" or "forwarded to the concerned team".

Zilog wishes to thank you, our forum participants, for writing to express your opinions. Your participation is very important to us, and we welcome the opportunity to respond. These forum posts are not falling on deaf ears here, and this particular post, for example, has been discussed internally and at length among the senior level of our organization.

It’s certainly understandable that sometimes things don’t seem to appear like they should. Nevertheless, we feel it is very important our audience understand that Zilog is focused on continually improving and expanding our products and toolsets. In reviewing this particular issue with Engineering, we determined that of the high-priority bugs that were formally brought to our attention, five out of five were fixed in the current version of the tools, and three of eight potential new features or different usage and optimization requests were also addressed; that’s basically 8/13 thus far. While that’s not perfect, it shows that Zilog is listening. The one really important point to make here is that, in order to effectively correct the issues that are discovered, folks need to create a Support Ticket via our Technical Support page so that it gets properly documented and channeled into the review queue for our Engineering team to address. We know that’s asking for everyone’s help here, but it makes a lot of difference toward fully characterizing and understanding an issue.

Additionally, as Zilog keeps moving forward, we feel it is important to point out that all bug fixes are reflected in the updated versions of our products. Zilog is a small team, yet Engineering is making every attempt to move forward. We do add all serious fixed bugs to our test cases to check against in future releases.

Lastly, the purpose of this forum is to bring the Zilog community together to share our collective thoughts and to demonstrate that our company is both reaching out and listening. We, as a company, cannot state enough just how much we do appreciate all of your support and good ideas.

Regards

Steve Darrough
VP of IXYS-Zilog Marketing
sdarrough@zilog.com