new literal && optimization

[josef angermeier]

i wrote a display driver for a lcd segment display which doesnt recognize
ascii character so that each character of an output string needs to be
converted byte by byte by looking in a const character table. in short,
when calling my output function display.output("hallo") i dont want to call
the output function at runtime with the ascii character string but with
display.output(CONVERTED("hallo")). ok therefor i could maybe write a macro
with a loop (must be difficult), but while reading bjarne stroustrup c++ i
just thought i could use implicit type conversion and maybe g++ optimizes
the conversion away.
i wrote a test class for this, but g++ doesnt optimize the conversion loop
away:

static const char table[] = {'j','o','s','e','f'};
class DisplayData{
public:
DisplayData(const char* str) : ptr(str) {
for(int i=0;i<5;i++){
const_cast<char*>(str) = table[const_cast<char*>(str)]; // each
byte is converted in another one
}
}
const char* ptr;
};
void output(const DisplayData& d){
cout << d.ptr << endl;
}
int main(){
const char str[] = "\00\01\02\03\04"; // the original character string
which should be optimized away
output(str);
}

any idea to get it optimized or another way to solve this problem ?

josef

 

[Karl Heinz Buchegger]

i wrote a display driver for a lcd segment display which doesnt recognize
ascii character so that each character of an output string needs to be
converted byte by byte by looking in a const character table. in short,
when calling my output function display.output("hallo") i dont want to call
the output function at runtime with the ascii character string but with
display.output(CONVERTED("hallo")). ok therefor i could maybe write a macro
with a loop (must be difficult), but while reading bjarne stroustrup c++ i
just thought i could use implicit type conversion and maybe g++ optimizes
the conversion away.
i wrote a test class for this, but g++ doesnt optimize the conversion loop
away:

static const char table[] = {'j','o','s','e','f'};
class DisplayData{
public:
DisplayData(const char* str) : ptr(str) {
for(int i=0;i<5;i++){
const_cast<char*>(str) = table[const_cast<char*>(str)]; // each
byte is converted in another one
}
}
const char* ptr;
};
void output(const DisplayData& d){
cout << d.ptr << endl;
}
int main(){
const char str[] = "\00\01\02\03\04"; // the original character string
which should be optimized away
output(str);
}

any idea to get it optimized

I don't think that you will find a compiler, which does this optimization
you intend. After all, you could do the translation by hand when you
write the code. But then: How many constant texts do you have in your
program, and is it really necessary to optimize them? Usually the
actual output to the device takes much longer then the table lookup.

or another way to solve this problem ?

Yup. Don't translate at the point of the call, but translate in
the output routine. The output routine will need to grab each
character as it is sent to the device. This is the place where
I would insert the translation step.

void output( const char* Text )
{
int Len = strlen( Text );
for( int i = 0; i < Len; ++i ) {
int Translated = table[ Text ];
Send_Translated_Character_to_Device( Translated );
}
}

 

[Ron Natalie]

int main(){

const char str[] = "\00\01\02\03\04"; // the original character string
which should be optimized away
output(str);
}

Not only is it unlikely to get optimized away, what you have written is undefined
behavior. You're lucky you got useful code at all, let alone what you wanted.

 

[Karl Heinz Buchegger]

hi! first thanks for your reply!


ok your right, its not a must-have feature but doing the table-lookup at
compile would make the ascii-to-bitmap-table unnecessary, which would save
me around 128 bytes. after all its just a simple loop, shouldnt this work
somehow ?

Are you that low on memory, that 128 bytes really hurt you? Even on my
small One-Card computer, I have a total of 2K RAM available (+8K EPROM)
and I wouldn't worry about 128 bytes for a translation table. If something
is needed, then it is needed.

Besides: How do you think should the translation process proceed
in case of non-constant texts? So it seems, no matter what you do,
you *will* need this table.

i extracted this conversion loop from the "write-to-lcd"-code because i
thought this would also help g++ to optimize it away

well, maybe i should after all use macros, but iv never done a loop with
macro...

You seem to have a wrong understanding of what Macros can do and
what they can not do.
The proprocessor is nothing more then a glorified text editor (roughly
speaking). The macro capability in this context is nothing more then a
'search and replace' facility embedded in the text you write (again
roughly speaking). The preprocessor replaces some text with some other
text and thats it.

 

[josef angermeier]

Are you that low on memory, that 128 bytes really hurt you? Even on my
small One-Card computer, I have a total of 2K RAM available (+8K EPROM)
and I wouldn't worry about 128 bytes for a translation table. If
something is needed, then it is needed.
Besides: How do you think should the translation process proceed
in case of non-constant texts? So it seems, no matter what you do,
you *will* need this table.

ok right, but unnecessary code wasting space remains for me evitable. your
right there could be also non const char arrays, if so this of course
should be converted at runtime but the others at compile time.

You seem to have a wrong understanding of what Macros can do and
what they can not do.

ok your right, but are you sure its absolutely not possible to do this with
c macros ? i think when using the nasm assembly macros can have compile
time loops and so i thought maybe the C preprocessor can so too....

using an external program for this is possible but not very convinient!