[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Bit number/mask, Part 3000
From: |
Ned Konz |
Subject: |
Re: [avr-libc-dev] Bit number/mask, Part 3000 |
Date: |
Wed, 5 Apr 2006 12:49:58 -0700 |
On Apr 4, 2006, at 9:21 PM, Markus Lampert wrote:
Hi everyone,
Since the discussion about bit masks (C-style) vs. bit numbers (ASM-
style)
seems to come up every now and then, here are my thoughts for what
they're
worth:
Atmel opted for the bit numbers for whatever reasons. That's that
and it's moot
to argue about it. The gcc port for AVR's chose early on to be as
compatible to
Atmel's lead as possible. That's also history. Good or bad, that's
where we
are.
I personally agree with Joerg that using bit masks would be the
'natural' way
in C (and all other non-assembler languages I know). But, there are
these guys
who still want to do assembler coding, at least every now and then
(including
myself). And nobody wants to maintain 2 sets of header files, which
is a good
idea.
But the bit masks can be easily generated from the existing ioXXX.h
files,
letting the compiler do the brunt work, as Eric pointed out. The
generation
can be integrated with the build process and nobody has to maintain
them
separately. All that is needed is a little convention (already in
place) during
the definition of the bit numbers.
I've attached a bash script that creates a
#define _XXXX _BV(XXXX)
for each XXXX that represents a bit number. Think of it as a proof
of concept.
You don't even have to go that far. You can still be compatible
without having to use different names. *That* is the best of all
possible worlds <g>.
I've attached a proof-of-concept that shows how the same file can be
used for either style (bitnums or bitmasks) in C, and also as bitnums
in assembler, and still allow unmodified old source code to work.
I've also shown one way of doing it in C++ (using templates so that
we get tight code generation), but I couldn't think of a clean way to
have named registers like I wanted, rather than #defines for C++, so
there would be a separate section (or perhaps a separate file,
included, which would make it easier to maintain) with a slightly
different syntax. Of course, this could be automatically generated
from the original headers.
I preferred to be able to write with the same syntax in C++ so I
could copy my source code over. The C++ is just a quick hack and is
not complete (or probably even correct!), but it shows the code
generation and syntax.
The way I did it retains backward compatibility with older sources
(in C, C++, or assembly language), and lets you switch at will to
also being able to use the newer style in C just using a single #define.
That is, you can still use the _BV(num) expressions transparently,
but if you define NEW_STYLE_PORTBITS (or whatever it's called) then
you can write *either*:
the old style:
TWCR |= (_BV(TWINT) | _BV(TWEA));
or the simplified usage:
TWCR |= (TWINT | TWEA);
even in the same program, and we can use the same set of defines for
assembly language as well.
That way you don't have to use new names.
hackio.tar.gz
Description: GNU Zip compressed data
--
Ned Konz
MetaMagix embedded consulting
address@hidden