Re: [avr-gcc-list] AVR Gcc with AVR Tiny

[Joerg Wunsch]

As Bruce D. Lightner wrote:

> >I don't think Bruce's method is limited to GCC 2.95, it's only that
> >this appears to be the compiler he likes best.

(Btw., you might note my choice of "appears" above...  As you didn't
state any reasoning about your decision for GCC 2.95 before, I could
only guess.)

> Joerg, as usual, you've got it "half right".

As well as you've got it almost completely wrong.

> I use avr-gcc 2.95 on older projects because I *have to*.

Because you think you have to?

> And *that* is because of the gratuitous changes to "avr-gcc" that
> *you* have made, seemingly in the name of "C-code cultural purity".

First, I didn't made any change to AVR-GCC at all: I'm not authorized
for that, I've got no commit rights for GCC.  I did, however, remove a
few macros in avr-libc that did nothing else but implement standard C
bit manipulation operations.  Please realize that -- I did by no means
kill any functionality by this.  (If converting an existing project to
standard C syntax was a technical problem for someone, I could easily
offer to spend the 5 minutes in my favorite editor to edit someone
else's project.  I've converted all my own projects that way, all it
takes is a few regular expression search&replace commands.)

> What I'm taking about is the rapid "deprecation", and then outright
> elimination of the low-level "avr-gcc" I/O constructs like sbi(),
> cbi(), in(), out(), etc.

Well, talking of "rapid" for a time frame of more than two years
appears to be quite impressive to me.

As for the "low-level"ness of these macros: see above, they
implemented simple C bit operations, nothing else.  Of course, you're
always free to roll your own if you think you need them.  After all,
I'm pretty sure that you (unlike a good number of newcomer AVR
programmers) know how to manipulate bits in C.

But wait, as you are referring to GCC 2.95...  That probably refers to
a change Marek made to both the compiler and the library long before I
even joined the avr-libc team, and which was generally considered to
be a good move (except as perhaps by you), as by that AVR-GCC (plus
avr-libc) was *finally* able to use standard C code snippets as they
can be found in any of the Atmel appnotes and documentation, instead
of requiring to roll your own macros for low-level IO (as it's
unfortunately still the case for reading the flash ROM).

But as you are whining about the low-level IO macros you're missing so
much from the newer library: did you ever look at their implementation
in the old compiler/library?  AFAICT, they were rather simple inline
assembly snippets (*).  I don't know why you aren't simply able to
continue using those old inline asm macros as part of your own ATtiny
setup but insist that only the use of an old, unmaintained compiler
can save your soul?  I see no reason why the old inline asm code
should not continue to work in a current compiler.

(*) They would quickly jump into your face as soon as one of your
parameters was out of range for these low-level instructions, leaving
you with a rather meaningless assembler error message (for code that
had already been accepted by the compiler itself) people usually
couldn't really make heads and tails out.  I only remember it's been a
support nightmare, as for each and any support requests, you had to
manually verify the people were actually applying the macros to the
correct IO registers...  And for any operation outside these IO
registers, people had to use standard C bit ops anyway (unlike with
the later versions of these macros, those I dared to eventually
remove, as they *were* standard C implementations only).

> As a result, people like me are stuck with avr-gcc 2.95 on older
> projects.

Sure, for *older* projects, I (and other people here as well)
completely agree that keeping the compiler that has been in use for
that project is probably the best idea.  Of course, until the day the
bug in your project turns out to be a bug in just *that* compiler that
has long since fixed...  but that would be a different story.

> It is unfortunate that "hobbyists" like you, the "B-Team"
> gatekeepers for "avr-gcc", don't "get it" when it comes to the
> *real* users of open source tools like GCC.

Thank you very much.

Incidentally, my current job makes me use that hobbyist software in an
industrial environment.  While I know I'm anything else but alone with
that, I'm pretty sure you'd never guess *whom* I'm currently working
for with that hobbyist software. ;-)

> To no small measure, companies like Microsoft are where they are
> today because *they* understand why *upward compatibility* is key to
> running a business efficiently.

Ouch.  If I were about collecting quotes for email signatures, I'd
collect that.  Please tell that to any of the frustrated MS word etc.
users who have been repeatedly struggling about upgrade nightmares.
Fortunately, it's not my problem, as I don't use their software.  I'm
not telling that MS gets everything wrong or such, but upward
compatibility is certainly not their shining side.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)