Re: [avr-gcc-list] Re: What Happened to the sbi() and cbi() Macros????

[Ned Konz]

On Monday 31 January 2005 5:30 am, Joerg Wunsch wrote:
> See my argumentation, in the end I think everyone should rather see
> this as a chance to improve their level of abstraction, and instead of
> blindly replacing cbi/sbi by another macro of the same function,
> invent a macro that is more descriptive in terms of what it does in
> that particular application (like turning LEDs on/off in my example).

First, I'm using bitfields when I can and making my own inline functions using 
the usual C operators when I can't. I have never used the cbi or sbi macros 
myself. So my code doesn't care.

But there *is* one interesting issue with legacy support like this:

There's lots of older code examples on the 'net that will live forever. And 
this code uses the cbi/sbi macros, and will never be re-written in a more 
modern style.

There are, I suspect, many people who'd like to use the AVR devices with GCC 
but don't necessarily want to learn too much C.

People still buy (or try to buy) the PIC 16F84A for hobby projects despite the 
fact that it's much more expensive than the newer PIC chips that do lots 
more. Why? Well, because when the first flash PICs came out there was a 
flurry of writing about them that included code examples. And that code is on 
the net.

Rather than reading both the datasheets of the 16F84A and a newer device, then 
figuring out how to convert the older code (and then figuring out how to use 
the newer on-chip peripherals instead of bit-banging, etc.), it's easier for 
people to copy an existing program and make incremental modifications to it. 
It's even possible that they'll get something (sort of) working before they 
wear out the flash. Of course, along the way they'll post lots of "it doesn't 
work" messages to various lists and boards, and people will point them to the 
FAQs, the datasheets, tell them that they shouldn't be using the 16F84, etc.

Perl grew rapidly because it was generally forgiving when you cut and pasted 
other peoples' code, modifying small bits. Because of this, we still see lots 
of questions on Perl lists and boards (I assume; I haven't really kept up 
with Perl, though I have a popular module on CPAN) relating to idioms from 
Perl 4, which is long gone.

When Perl 6 appears, I expect there to be a huge increase of such questions.

And it will also be an increased support burden, given that people will be 
asking new questions.

And has been pointed out here, the removal of these macros is an annoyance for 
(even knowledgeable) people with working code who don't want to re-write 
their code.

In all fairness, though, it's not uncommon to have to re-write old code when 
compilers or libraries change. I'm one of the leaders of the Squeak 
(Smalltalk) project; there's quite a bit of older code that we've managed to 
break as we've evolved Squeak. We have never said "this is a part of the 
system that is guaranteed never to change", and we've had to balance the 
needs of legacy code with our desires to evolve the system.

What many embedded developers do (myself included) for code that is in the 
field is to stick to the compiler and library version that was originally 
used to compile and debug a given program. This avoids breakage as compilers 
and libraries change.

However, it means that if you want to re-use your old code in newer projects 
you may have to re-write it if it uses features that are no longer available.

This is an unavoidable price of keeping up with new tools. In the absence of a 
standard, I don't know of a single (evolving) project in which old code is 
guaranteed to work perfectly with newer tools, compilers, and libraries. And 
there is no "standard" for avr-libc; there's only historical versions.

I just ran across a dramatic demonstration of this when trying to modify a 
Palm program that someone else wrote for Palm OS 1. There was a massive 
renaming that happened somewhere after that version of Palm OS in which even 
type names changed. Some library routines (that still exist in the ROMs) are 
no longer even declared, as they've become deprecated. People grumbled and 
put up with this, apparently, but Palm decided that they needed to do the 
renaming and reorganization to go forward.

So what's the answer?

I can think of several:

(1) somehow make the compiler warn clearly if and when these macros are used. 
I don't know how to do this, though.

(2) provide the macros forever for backwards compatibility, but make them 
correct. Put them in a standard header. Label them clearly as deprecated, and 
include a pointer to a description of the alternatives. But make their 
inclusion depend on the definition of another macro.

So to get old code to compile, you'd have to do something like:

avr-gcc -DGIVE_ME_THE_OLD_CBI_AND_SBI_MACROS_PLEASE  ...

(3) make a conversion program that can modify old code in place. Somehow make 
it really clear that people should use it to help them migrate old code. In 
the case of cbi() and sbi() this could be a simple Perl script:

---
#!/usr/bin/perl -pi.bak
# Rewrite sbi() and cbi() macro usage
# Will make backup files with .bak extensions when run as described.
#
# Usage:
#  perl -pi.bak file [...]

# cbi(reg,bit)
s/\bcbi\s*\(\s*([^,)]+)\s*,\s*([^,)]+)\s*\)/$1 &= ~($2)/g;

# sbi(reg,bit)
s/\bsbi\s*\(\s*([^,)]+)\s*,\s*([^,)]+)\s*\)/$1 |= $2/g;
---

-- 
Ned Konz
http://bike-nomad.com