enum as char ?

[d.kaufmann]

i have this part of code:

typedef enum
{
OW_SEARCH_ROM = 0xF0,
OW_MATCH_ROM = 0x55,
OW_CONDITIONAL_SEARCH_ROM = 0xEC,
OW_HANDLE_SELECT = 0x0F
} ow_command_t;

ow_command_t command;


now "command" will be represented as int,
wich is a 16bit on my architecture. how can
i force the representation to be char ?

 

[Eric Sosman]

i have this part of code:

typedef enum
{
OW_SEARCH_ROM = 0xF0,
OW_MATCH_ROM = 0x55,
OW_CONDITIONAL_SEARCH_ROM = 0xEC,
OW_HANDLE_SELECT = 0x0F
} ow_command_t;

ow_command_t command;


now "command" will be represented as int,
wich is a 16bit on my architecture. how can
i force the representation to be char ?

You cannot. The compiler chooses an underlying
type for the enum, and you cannot control its choice.
(Well, in one sense you can: The underlying type must
be able to represent all the enumerated values, so
you can *prevent* the compiler from choosing `char' by
including a value like 0xB00B in the list. But that's
not the kind of "control" you want.)

I suggest you use the enum only to declare the
values of the enumerated constants, and use a separate
typedef:

enum { OW_ ... };
typedef unsigned char ow_command_t;
ow_command_t command;

Things like `command = OW_CONDITIONAL_SEARCH_ROM;' and
`if (command == OW_SEARCH_ROM)' will still work. The
only drawback I can think of is that some compilers will
issue warnings if you `switch' on an enumerated type and
do not provide `case' labels for all the values; these
warnings can be helpful.

switch (command) {
case OW_SEARCH_ROM: /* search ROM */
... break;
case OW_MATCH_ROM: /* set ROM aflame */
... break;
case OW_CONDITIONAL_SEARCH_ROM: /* maybe search
... break;
case OW_HANDLE_SELECT: /* select a handle */
... break;
}

A compiler that issued warnings for missing cases would
draw your attention to this error if `command' were an
enumerated type, but probably would not issue any warning
if `command' were an ordinary `unsigned char'.

 

[d.kaufmann]

previously it was codes via #define i changed that
to enum exactly besauce i want the compiler (gcc)
to produce a warning on incomplete switch statements.

just cause my architecture is 8-bit (Amtel) i need to have 8
bit-values here, 16-bit values result in larger and slower code ;(

 

[Keith Thompson]

previously it was codes via #define i changed that
to enum exactly besauce i want the compiler (gcc)
to produce a warning on incomplete switch statements.

just cause my architecture is 8-bit (Amtel) i need to have 8
bit-values here, 16-bit values result in larger and slower code ;(

Then you can use the 16-bit enum type for your switch statements:

enum ow_command {
OW_SEARCH_ROM = 0xF0,
OW_MATCH_ROM = 0x55,
OW_CONDITIONAL_SEARCH_ROM = 0xEC,
OW_HANDLE_SELECT = 0x0F
};

typedef unsigned char ow_command_t;

...

ow_command_t foo = whatever;
switch((enum ow_command)foo) {
case OW_SEARCH_ROM: ...
case OW_MATCH_ROM: ...
case OW_CONDITIONAL_SEARCH_ROM: ...
case OW_HANDLE_SELECT: ...
}

Note that this will convert the value of foo (8 bits) to type enum
ow_command (16 bits) for the switch statement. If that's going to be
a performance problem, you can define a conversion macro that either
does the conversion (to get the warnings) or that does nothing (for
greater performance); you can control how the macro is defined at
compilation time:

enum ow_command {
OW_SEARCH_ROM = 0xF0,
OW_MATCH_ROM = 0x55,
OW_CONDITIONAL_SEARCH_ROM = 0xEC,
OW_HANDLE_SELECT = 0x0F
};

typedef unsigned char ow_command_t;

...

#ifdef WANT_WARNINGS
#define ENUM_OW_COMMAND(x) ((enum ow_command)(x))
#else
#define ENUM_OW_COMMAND(x) (x)
#endif

ow_command_t foo = whatever;
switch (ENUM_OW_COMMAND(foo)) {
case OW_SEARCH_ROM: ...
case OW_MATCH_ROM: ...
case OW_CONDITIONAL_SEARCH_ROM: ...
case OW_HANDLE_SELECT: ...
}

Warning: I haven't tried compiling any of this; it may be full of
typos and/or stupid errors.

All of this (potentially) makes your generated code smaller and faster
at the expense of obfuscating your source code. Like any manual
optimization, you should actually measure the performance before
deciding whether the tradeoff is worthwhile. You may even find that
your compiler, with the proper options, can do a better job of
micro-optimization than you can.

 

[John Temples]

just cause my architecture is 8-bit (Amtel) i need to have 8
bit-values here, 16-bit values result in larger and slower code ;(

I would complain to the vendor if a compiler for an eight-bit target
were generating 16-bit accesses for an enum that had eight-bit values.
I don't run into this problem with eight-bit compilers I use.

 

[Ross A. Finlayson]

Hi,

I'm wondering about how to use enum.

It's up to the compiler to determine what integer type the enum is, in
C. Basically it's an int, but the enums I'm using are all with literal
values less than 256, i.e. they fit in an octet or 8-bit byte.


Then, when the enum is defined, there's something like this, with
regards to previous considerations about struct_tag and s_cast:

#ifndef use_enums

#define A 0
#define B 1
#define C 2

typedef uint_8 X_t;

#define e_cast8(x) x
#define e_cast(x)

#endif

#ifdef use_enums

enum_kw(typedef) enum enum_tag(X_t){
A = 0,
B = 1,
C = 2
} enum_td(X_t);

#define e_cast8(x) s_cast(uint_8)(x)
#define e_cast(x) s_cast(x)

#endif

Then, with these ugly preprocesor definitions, the user can configure
at the single-point-of-change file whether to use enums or not, and
whether to use the tag and typedef and stuff or not, at compile time.

X_t letter = A;
uint_8 c;
switch(letter){
case A:
c = e_cast8(letter)
break;
case B:
c = e_cast8(letter)
break;
case C:
c = e_cast8(letter)
break;
default:
break;
}

Anyways my idea about compiling with enums or not here is probably
again useless. The only reason I like enums is because in the debugger
it shows as the enum instead of the integer, but in general it is not
possible to standardly demand the enum be any type other than at least
some type in which it fits. I just need the enumerated value to be a
fixed width, preferably the least necessary integer multiple of eight
bits.

A problem with the macros in the type definitions is that some
automatic code documentations generators don't, or rather, doxygen
doesn't, process the macro so the types don't appear in the listings.
So I'm wondering whether to it is worth that, or to selectively
preprocess those macros before documentation generation.


This is about a separate issue, but it took a bunch of iterations to
figure out how to selectively include a file based upon concatenation
of some identifier fragment with the string. I use:

#define PLATFORM_BYTE_ORDER_INCLUDE(x) #x "_be.h"

Then I can use

#include
PLATFORM_BYTE_ORDER_INCLUDE(function_with_several_encoded_variations)

to say

#include "function_with_several_encoded_variations_be.h"

I think that works when a variety of other combinations about passing a
quoted string to #include don't for some reason, it merges the
resulting strings _before_ passing it to #include, but I don't know how
it will behave in the general case for preprocessors, or if there is
some canonical way to do that.

Regards,

Ross F.

 

[d.kaufmann]

omg ! my primary goal was to make the code easier to understand
and have warnings about missing cases. theese macroes do make
it harder to read.
i just got back to the good old #defines. i checked everything about
my compiler, if theres an option to use 8bit enums but didn't find any.

 

[d.kaufmann]

i am using a modified gnu c version. the 8bit - 16bit issues are well
known by the designers and it occurs in some other areas.

for example

char foo(char);

parameter as well as return value are passed through 2 8bit registers.


I can't complain about this, cause i know the developers do the best
they can in their free time. I just hope that this will be fixed someday.