[Coco] Found strangeness in C compiler (bug)

Mathew Boytim maboytim at yahoo.com
Wed May 22 08:39:05 EDT 2019


 I don't want to derail the discussion.  But the problem isn't so much it's the compiler, it's the runtime (I think mostly IO/fileIO).  I think z88dk is the one I looked at and it supports the 'trs-80' but there are several z-80 models and several DOS's.  I think they might mean Model 1/3 and I tried it with Model 4 and LDOS.  I will have to try in in Model 3 mode.
Thanks,
Matt
    On Tuesday, May 21, 2019, 10:45:35 AM EDT, Alex Evans <varmfskii at gmail.com> wrote:  
 
 getting waaaay of topic: if you are looking for a good C compiler for
the model 1/3/4 (or pretty much anything using a Z80, not i8080, CPU),
you should look into z88dk.

On Tue, May 21, 2019 at 8:33 AM Mathew Boytim via Coco
<coco at maltedmedia.com> wrote:
>
>  The 80 character thing seems to be a limitation of that implementation.  I seem to recall the PIC compiler had some oddities because of its Harvard architecture - I think there was for example a special character type for constant strings stored in ROM (Flash) - otherwise they are initialized in RAM.
> I'm not a coco guy - I'm a M1/3/4 guy - I monitor the coco list just because there are interesting discussions.  I just recently got back into it - back in the day I programmed almost exclusively in assembler but today I just don't have the energy except where I have to (like hard disk driver for LS-DOS I'm working on).  I'm still looking for a good c compiler for the M1/3/4.  There is an old K&R compiler but it's a bit painful to use.  Sdcc might be a good choice - it supports the TRS-80 but I'm not sure for which machine and which DOS (didn't work for my test).
> Matt
>    On Tuesday, May 21, 2019, 9:24:49 AM EDT, Allen Huffman <alsplace at pobox.com> wrote:
>
>  > On May 21, 2019, at 8:16 AM, Mathew Boytim via Coco <coco at maltedmedia.com> wrote:
> >
> > ...
> > not strictly legal.  We use IAR for a lot of embedded development and the IAR compiler/optimizer is pretty kind in that it seems to do things as you would want or expect but aren't strictly legal/defined.  On the other hand I find the gcc compiler/optimizer to be 'greedy' in that it takes advantage of the strict definition when it wants to.  I frequently encounter programmers complaining of bugs in gcc because things that they routinely do with IAR don't work with gcc - but in all cases gcc has been right.
> > Matt
>
> I used IAR at a recent job. I know we “complain” about issues with these ancient K&R compilers from the 1980s, but I found some odd limits in “modern” supported compilers. It was either IAR or Renasas that had a cryptic error if you had a string longer than 80 characters or something pretty small!
>
> char * string = “If this is too big, it would give you an error that you had to look up because it did not make any sense.”;
>
> I guess the biggest thing we’ve gained with modern tools is they have much better error reporting, and we can search the web to see what they mean.
>
> I am hoping I can slide back into K&R C for updating some of my old projects. I assume using ANSIFRONT is going to bloat my code a bit — especially if I use things like unsigned char where it puts in “ch & 255” everywhere (if I recall).
>
> I guess if ANSIFRONT is standard with NitrOS-9 these days, maybe I should just go that route. It sure would be easier.
>
>        — Allen
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco

-- 
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco
  


More information about the Coco mailing list