---

Hey

Hvordan får jeg 4 bytes med ud af en function ??

pointer til et array ???

Kasper

---

Kasper wrote:

> Hvordan får jeg 4 bytes med ud af en function ??

gcc tolker en int er en 32 bits variabel (4 bytes)...

> pointer til et array ???

I så fald bør denne sendes til funktionen som parameter:

void funktion(char *returvariabel) {
retur[X] = ..;
}

/Jesper

---

> Hvordan får jeg 4 bytes med ud af en function ??

Da de 4 bytes sikkert alligevel har noget med hinanden at
gøre, kunne det give mening at pakke dem ind i en struct
og returnere denne.

Noget i stil med:

typedef struct {
char byte0;
char byte1;
char byte2;
char byte3;
} struct_of_bytes;

struct_of_bytes get_struct()
{
struct_of_bytes s = {0, 1, 2, 3};
return s;
}

int main(int argc, char *argv[])
{
struct_of_bytes s = get_struct();
printf("%d %d %d %d\n", s.byte0, s.byte1, s.byte2, s.byte3);
...
}

---

"Morten F. Hansen" <all.your.base@are.belong.to.us> wrote in message
news:bsrei0$c4k$1@sunsite.dk...
> > Hvordan får jeg 4 bytes med ud af en function ??
>
> Da de 4 bytes sikkert alligevel har noget med hinanden at
> gøre, kunne det give mening at pakke dem ind i en struct
> og returnere denne.
>
> Noget i stil med:
>
> typedef struct {
> char byte0;
> char byte1;
> char byte2;
> char byte3;
> } struct_of_bytes;
>
> struct_of_bytes get_struct()
> {
> struct_of_bytes s = {0, 1, 2, 3};
> return s;
> }
>
> int main(int argc, char *argv[])
> {
> struct_of_bytes s = get_struct();
> printf("%d %d %d %d\n", s.byte0, s.byte1, s.byte2, s.byte3);
> ...
> }

Hey

hvad laver det S "struct_of_bytes s"

KAn ikke få det til at køre i min compiler

Kasper

---

> hvad laver det S "struct_of_bytes s"

Det burde erklære en variabel, kaldet s, af typen
struct_of_bytes.

> KAn ikke få det til at køre i min compiler

Hmm... Det virker i min Visual C++ både som C og C++ kode, men
derfor kan det jo godt være forkert alligevel Hvilken fejl
får du? Og hvordan ser linien ud, som laver fejlen?

---

Hey

Fejl :

C:\atmega\icc\bin\imakew -f LCDPROJECT.mak
iccavr -c -IC:\atmega\icc\include -e -DATMEGA -l -g -Mavr_enhanced
F:\uC\LCDFIL~1\LCD.C
!E F:\uC\LCDFIL~1\LCD.C(39): illegal use of type name `struct_of_bytes'
!W F:\uC\LCDFIL~1\LCD.C(39):[warning] expression with no effect elided
!E F:\uC\LCDFIL~1\LCD.C(39): syntax error; found `s' expecting `;'
!E F:\uC\LCDFIL~1\LCD.C(39): undeclared identifier `s'
!E F:\uC\LCDFIL~1\LCD.C(39): illegal expression
!E F:\uC\LCDFIL~1\LCD.C(39): syntax error; found `0' expecting `;'
!W F:\uC\LCDFIL~1\LCD.C(39):[warning] expression with no effect elided
!W F:\uC\LCDFIL~1\LCD.C(39):[warning] expression with no effect elided
!W F:\uC\LCDFIL~1\LCD.C(39):[warning] expression with no effect elided
!W F:\uC\LCDFIL~1\LCD.C(39):[warning] expression with no effect elided
!E F:\uC\LCDFIL~1\LCD.C(39): syntax error; found `}' expecting `;'
!W F:\uC\LCDFIL~1\LCD.C(39):[warning] missing return value
!W F:\uC\LCDFIL~1\LCD.C(39):[warning] empty declaration
!E F:\uC\LCDFIL~1\LCD.C(40): unrecognized declaration
!E F:\uC\LCDFIL~1\LCD.C(43): unrecognized declaration
!E F:\uC\LCDFIL~1\LCD.C(104): illegal use of type name `struct_of_bytes'
!W F:\uC\LCDFIL~1\LCD.C(104):[warning] expression with no effect elided
!E F:\uC\LCDFIL~1\LCD.C(104): syntax error; found `s' expecting `;'
!E F:\uC\LCDFIL~1\LCD.C(104): operands of = have illegal types `int' and
`struct_of_bytes'
!W F:\uC\LCDFIL~1\LCD.C(104):[warning] expression with no effect elided
C:\atmega\icc\bin\imakew.exe: Error code 1
Done: there are error(s). Exit code: 1



CODE :

typedef struct {
char d0;
char d1;
char d2;
char d3;
} struct_of_bytes;

struct_of_bytes pc73recieve()
{
unsigned char tjeck=0;
do
{
pc74start();
tjeck = pc74send(0XD1); // send adresse
TWCR |= 0x40; // send ack bytes
tjeck |= pc74recieve(); // Recieve data
tjeck |= pc74recieve();
tjeck |= pc74recieve();
TWCR &= 0xBF; // sen ikke ack
tjeck |= pc74recieve();
pc74stop();
}
while(tjeck==1); // continues until all data is correct

struct_of_bytes s = {0, 1, 2, 3};
return s;
}





CALL :

struct_of_bytes s = pc73recieve();

Godt nytår Kasper

---

Repzak wrote:
> Hey
>
> Fejl :
>
> C:\atmega\icc\bin\imakew -f LCDPROJECT.mak
> iccavr -c -IC:\atmega\icc\include -e -DATMEGA -l -g -Mavr_enhanced
> F:\uC\LCDFIL~1\LCD.C
> !E F:\uC\LCDFIL~1\LCD.C(39): illegal use of type name `struct_of_bytes'
> !W F:\uC\LCDFIL~1\LCD.C(39):[warning] expression with no effect elided
> !E F:\uC\LCDFIL~1\LCD.C(39): syntax error; found `s' expecting `;'
> !E F:\uC\LCDFIL~1\LCD.C(39): undeclared identifier `s'
> !E F:\uC\LCDFIL~1\LCD.C(39): illegal expression
> !E F:\uC\LCDFIL~1\LCD.C(39): syntax error; found `0' expecting `;'
> !W F:\uC\LCDFIL~1\LCD.C(39):[warning] expression with no effect elided
> !W F:\uC\LCDFIL~1\LCD.C(39):[warning] expression with no effect elided
> !W F:\uC\LCDFIL~1\LCD.C(39):[warning] expression with no effect elided
> !W F:\uC\LCDFIL~1\LCD.C(39):[warning] expression with no effect elided
> !E F:\uC\LCDFIL~1\LCD.C(39): syntax error; found `}' expecting `;'
> !W F:\uC\LCDFIL~1\LCD.C(39):[warning] missing return value
> !W F:\uC\LCDFIL~1\LCD.C(39):[warning] empty declaration
> !E F:\uC\LCDFIL~1\LCD.C(40): unrecognized declaration
> !E F:\uC\LCDFIL~1\LCD.C(43): unrecognized declaration
> !E F:\uC\LCDFIL~1\LCD.C(104): illegal use of type name `struct_of_bytes'
> !W F:\uC\LCDFIL~1\LCD.C(104):[warning] expression with no effect elided
> !E F:\uC\LCDFIL~1\LCD.C(104): syntax error; found `s' expecting `;'
> !E F:\uC\LCDFIL~1\LCD.C(104): operands of = have illegal types `int' and
> `struct_of_bytes'
> !W F:\uC\LCDFIL~1\LCD.C(104):[warning] expression with no effect elided
> C:\atmega\icc\bin\imakew.exe: Error code 1
> Done: there are error(s). Exit code: 1
>
>
>
> CODE :
>
> typedef struct {
> char d0;
> char d1;
> char d2;
> char d3;
> } struct_of_bytes;
>
> struct_of_bytes pc73recieve()
> {
> unsigned char tjeck=0;
> do
> {
> pc74start();
> tjeck = pc74send(0XD1); // send adresse
> TWCR |= 0x40; // send ack bytes
> tjeck |= pc74recieve(); // Recieve data
> tjeck |= pc74recieve();
> tjeck |= pc74recieve();
> TWCR &= 0xBF; // sen ikke ack
> tjeck |= pc74recieve();
> pc74stop();
> }
> while(tjeck==1); // continues until all data is correct
>
> struct_of_bytes s = {0, 1, 2, 3};
> return s;
> }

Det er ikke alle C compilere der tillader at man laver lokale
variaber andre steder end i starten af en blok, dvs. efter en
{.

Prøv at flytte "struct_of_bytes s = {0, 1, 2, 3};" op til starten
af funktionen (før eller efter "unsigned char tjeck=0;").

/b

---

> Prøv at flytte "struct_of_bytes s = {0, 1, 2, 3};" op til starten
> af funktionen (før eller efter "unsigned char tjeck=0;").

Har akkurat lige fået det til at virke efter lidt læsning her :

http://www.strath.ac.uk/IT/Docs/Ccourse/subsection3_12_2.html

så d et spiller bare nu... mange TAK alle sammen

men det er sandt som du skriver med op til starten, men jeg havde bare ikke
fatter den var en declaring, jeg troede man puttede værdierne i en
variabel... Tsk Tsk (nybegynder)

Kasper

---

Hey igen

Kan den structures egentlig decalres localt hvorfra den bliver kaldt ??

for at mindske ram brugen ??

jeg får fejl fordi den ikke er decalret når den "compiler" min function den
bliver brugt i, inden functionen den bliver kaldt fra

Kasper

---

Repzak wrote:
> Hey igen
>
> Kan den structures egentlig decalres localt hvorfra den bliver kaldt ??
>
> for at mindske ram brugen ??
>
> jeg får fejl fordi den ikke er decalret når den "compiler" min function den
> bliver brugt i, inden functionen den bliver kaldt fra
>
> Kasper
>
>
Jeg er ikke sikker på at jeg forstår, men;

Du kan ikke lave typen lokalt i funktionen, den skal jo også
kendes derfra hvor du kalder funktionen.

Du kan lave strukturen lokalt i den funktion der kalder, og så
give den kaldte funktion en pointer til strukturen, hvilket måske
er en anelse mere optimalt.

void pc73recieve(struct_of_bytes *whatever)
{
whatever->d0 = 1234;
...
}

Og kaldet:

struct_of_bytes MyStruct;
pc73recieve(&MyStruc);

/b

---

> Jeg er ikke sikker på at jeg forstår, men;
>
> Du kan ikke lave typen lokalt i funktionen, den skal jo også
> kendes derfra hvor du kalder funktionen.
>
> Du kan lave strukturen lokalt i den funktion der kalder, og så
> give den kaldte funktion en pointer til strukturen, hvilket måske
> er en anelse mere optimalt.

Problemet ligger im den function som jeg kalder, ligger i en include ful,
som jeg includere først...

så når compileren includere den, kommer den til den variabel i funktionen
der bliver kaldt, og der er den jo ikke kend af compileren hvad det er (tror
det er det der er problemet)

Kasper

---

Kasper wrote:
>>Jeg er ikke sikker på at jeg forstår, men;
>>
>>Du kan ikke lave typen lokalt i funktionen, den skal jo også
>>kendes derfra hvor du kalder funktionen.
>>
>>Du kan lave strukturen lokalt i den funktion der kalder, og så
>>give den kaldte funktion en pointer til strukturen, hvilket måske
>>er en anelse mere optimalt.
>
>
> Problemet ligger im den function som jeg kalder, ligger i en include ful,
> som jeg includere først...
>
> så når compileren includere den, kommer den til den variabel i funktionen
> der bliver kaldt, og der er den jo ikke kend af compileren hvad det er (tror
> det er det der er problemet)
>

Man laver normalt ikke funktioner i header-filer, kun prototypen, selve
funktionen putter man normalt i en .c fil.

Hvis du har prototypen i en .h-fil skal du også have typedef'en i
headerfilen.

F.ex:

my.h

typedef struct {
char d0;
char d1;
char d2;
char d3;
} struct_of_bytes;

extern void pc73recieve(struct_of_bytes *sob);

one.c:

void pc73recieve(struct_of_bytes *sob)
{
sob->d3 = 12;
}

two.c:

int main(void)
{
struct_of_bytes MyStruct;
pc73recieve(&MyStruct);
return 0;
}

/b

---

>
> Man laver normalt ikke funktioner i header-filer, kun prototypen, selve
> funktionen putter man normalt i en .c fil.
>
> Hvis du har prototypen i en .h-fil skal du også have typedef'en i
> headerfilen.

Men.. hmm... ja jeg er jo ikke så dygtig endnu.. men ligger den så ikke
declaret hele tiden i rammen også ??

har jo kun 4 kb ram at gøre godt med

Kasper

---

Kasper wrote:
>>Man laver normalt ikke funktioner i header-filer, kun prototypen, selve
>>funktionen putter man normalt i en .c fil.
>>
>>Hvis du har prototypen i en .h-fil skal du også have typedef'en i
>>headerfilen.
>
>
> Men.. hmm... ja jeg er jo ikke så dygtig endnu.. men ligger den så ikke
> declaret hele tiden i rammen også ??
>

En typedef er kun en definition af en type, en typedef fylder ingenting,
hverken i ram eller rom, struct_of_bytes er kun en type.

Variable ligger i ram, hvis du vil have 4 bytes tilbage fra en funktion,
er du nødt til at gemme dem et eller andet sted.

/b

---

>
> En typedef er kun en definition af en type, en typedef fylder ingenting,
> hverken i ram eller rom, struct_of_bytes er kun en type.
>
> Variable ligger i ram, hvis du vil have 4 bytes tilbage fra en funktion,
> er du nødt til at gemme dem et eller andet sted.

Sorry jeg er besværlig, og sætter meget pris på din hjælp !!

tror jeg har forstået lidt af det nu..

dvs.

typedef struct {
unsigned char d0;
unsigned char d1;
unsigned char d2;
unsigned char d3;
}recdata;



recdata r_data; <-- det er først herfra den fylder i rammen og til den
function hvor den ligger i er slut ??

hvis man bare skriver struct og ikke typedef, så fylder den hele tiden ?,
hvis den er global?



Kasper

---

Repzak wrote:

>>En typedef er kun en definition af en type, en typedef fylder ingenting,
>>hverken i ram eller rom, struct_of_bytes er kun en type.
>>
>>Variable ligger i ram, hvis du vil have 4 bytes tilbage fra en funktion,
>>er du nødt til at gemme dem et eller andet sted.
>
>
> Sorry jeg er besværlig, og sætter meget pris på din hjælp !!
>
> tror jeg har forstået lidt af det nu..
>
> dvs.
>
> typedef struct {
> unsigned char d0;
> unsigned char d1;
> unsigned char d2;
> unsigned char d3;
> }recdata;
>
> recdata r_data; <-- det er først herfra den fylder i rammen og til den
> function hvor den ligger i er slut ??
Korrekt, recdate er en type, r_data er en variabel. Typer tager ikke
plads, variabler gør.

Man kan godt lave variabler andre steder end i starten af en funktion:

void f(int x)
{
if(x)
{
recdata r_data;
...
}
else
{

}
...
}
Her vil r_data kun optage plads hvis x er != 0. (hvis du har en god
compiler, nogle compilere vil afsætte plads til r_data fra starten af
funktionen, til den slutter).
>
> hvis man bare skriver struct og ikke typedef, så fylder den hele tiden ?,
Hvis man har:

struct
{
int x;
int y;
}xy;

Så er xy en variabel, dvs. ikke en type. Den vil som sådan fylde op
fra den er erklæret til slutningen på den blok den er erklæret i.

> hvis den er global?

Hvis xy (eller r_data) er global (dvs. erklæret uden for en funktion)
vil den tage plads fra programmet starter til det slutter (hvis det
slutter).

/b

---

[ Bertel Brander ]

[ ... ]

> Her vil r_data kun optage plads hvis x er != 0. (hvis du har en god
> compiler, nogle compilere vil afsætte plads til r_data fra starten
> af funktionen, til den slutter).


Det kommer vel strengt tatt an på innhold av else-grenen.

[ ... ]





ivr
--
<html><form><input type crash></form></html>

---

> >
> > hvis man bare skriver struct og ikke typedef, så fylder den hele tiden
?,
> Hvis man har:
>
> struct
> {
> int x;
> int y;
> }xy;
>
> Så er xy en variabel, dvs. ikke en type. Den vil som sådan fylde op
> fra den er erklæret til slutningen på den blok den er erklæret i.
>

Hvorfor er det at alle er så forelskede i "unnamed structs". Giv da structet
et navn, så kan du også lave forward declarations til den hvis du får brug
for det.
(Svar: Vistnok fordi gamle kompilere kan virke vrangvillige ifb med at
overføre en struct som parameter til en funktion etc. Men hvor mange har
egentlig dette problem nu?)

struct myXYtype
{
int x;
int y;
};
// bruger ingen hukommelse

if (blah)
{
myXYtype xy;
}
else
{
}

---

Troels Thomsen wrote:

>>struct
>>{
>> int x;
>> int y;
>>}xy;
>>
>>Så er xy en variabel, dvs. ikke en type. Den vil som sådan fylde op
>>fra den er erklæret til slutningen på den blok den er erklæret i.
>>
>
>
> Hvorfor er det at alle er så forelskede i "unnamed structs". Giv da structet
> et navn, så kan du også lave forward declarations til den hvis du får brug
> for det.

Hvorfor skal man lave en type, hvis man ikke har brug for en type?

>
> struct myXYtype
> {
> int x;
> int y;
> };
> // bruger ingen hukommelse
>
> if (blah)
> {
> myXYtype xy;

I C (svjv programmerer Kasper i C) skal man skrive:

struct myXYtype xy;

/b

---

> Hvorfor skal man lave en type, hvis man ikke har brug for en type?
>
Det er ikke mig der typedef'er. Hvad mener du?


> I C (svjv programmerer Kasper i C)
>
Point taken
(har selv programmeret en atmel microcontroller men det var i en Iar c++
compiler som jo ikke behøvede 'struct')

---

Troels Thomsen wrote:
>>Hvorfor skal man lave en type, hvis man ikke har brug for en type?
>>
>
> Det er ikke mig der typedef'er. Hvad mener du?
>

Der er ikke nogen der typedef'er, men du lavede en type med:

struct myXYtype
{
int x;
int y;
};

"struct myXYtype" er en type (i C++ er myXYtype en type).

/b

---

> Der er ikke nogen der typedef'er, men du lavede en type med:
>

Det jeg svarede på var

typedef struct /*her skulle navnet have stået*/ {
unsigned char d0;
unsigned char d1;
unsigned char d2;
unsigned char d3;
}recdata;

(som er et unnamed struct)

mvh Troels

---

"Kasper" <RepzakRemoveme@hotmail.com> wrote:

>har jo kun 4 kb ram at gøre godt med

Det stadig AVR programmet "der spøger" ?

Når jeg skal have fat i de enkelte char's i int og long variable bruger jeg
følgende macroer:

Til og fra int:
#define LO(x) *(((uchar*)(&(x)))+0)
#define HI(x) *(((uchar*)(&(x)))+1)

Til og fra long:
#define LONG0(x) *(((uchar*)(&(x)))+0)
#define LONG1(x) *(((uchar*)(&(x)))+1)
#define LONG2(x) *(((uchar*)(&(x)))+2)
#define LONG3(x) *(((uchar*)(&(x)))+3)

I HiTech PIC-C compileres disse makroer til rene 8-bit's instruktioner.

Med følgende temporære variable: ScrChar, ScrInt og ScrLong kan man gøre
følgende:

HI(ScrInt) = ScrChar;
ScrChar = LO(ScrInt);

LONG1(ScrLong) = ScrChar;
ScrChar = LONG3(ScrLong);

Følgende burde også være gangbar:

LO(ScrInt) = LONG2(ScrLong);

Og til sidst en lille advarsel, disse macroer er der lige så lidt typecheck på
som alle andre steder i et C program.


--
Med venlig hilsen, Ove Kjeldgaard, nospam AT privat DOT dk
Natur og Friluftsliv: <http://hiker.dk>

---

"Kasper" <RepzakRemoveme@hotmail.com> skrev i en meddelelse
news:3ff0d426$0$167$edfadb0f@dread11.news.tele.dk...
> Hey
>
> Hvordan får jeg 4 bytes med ud af en function ??
>
> pointer til et array ???
>
> Kasper
>
>

Du kan pakke de 4 bytes op i et longword, det kunne F.eks. se sådan ud:

- Kodefragment

char a, b, c, d = {0xFE,0xFE,0xFE,0xFE};
long ret = 0x00000000;

ret = a;
ret = ret << 8 && b; // Skift 8 bit til venstre, og put den næste byte ind
ret = ret << 8 && c; //
ret = ret << 8 && d; //

return ret;

- Kodefragment

Det kan godt virke lidt nørdet at bruge de binære operatorer, men det er
utroligt hurtigt at udføre for processoren, og en meget brugt teknik i
assembler, og særligt til billedbehandling, hvor der dog sker en hel del
mere smiden rundt med bits på kryds og tværs i registre og hukommelse.

Mvh

Per Pedersen

---

"Per Pedersen" <perpedersen33@hotmail.com> wrote in message
news:3ff24ef3$0$17597$ba624c82@nntp05.dk.telia.net...
>
> "Kasper" <RepzakRemoveme@hotmail.com> skrev i en meddelelse
> news:3ff0d426$0$167$edfadb0f@dread11.news.tele.dk...
> > Hey
> >
> > Hvordan får jeg 4 bytes med ud af en function ??
> >
> > pointer til et array ???
> >
> > Kasper
> >
> >
>
> Du kan pakke de 4 bytes op i et longword, det kunne F.eks. se sådan ud:
>
> - Kodefragment
>
> char a, b, c, d = {0xFE,0xFE,0xFE,0xFE};
> long ret = 0x00000000;
>
> ret = a;
> ret = ret << 8 && b; // Skift 8 bit til venstre, og put den næste byte ind
> ret = ret << 8 && c; //
> ret = ret << 8 && d; //

Du mener vist

ret = ret << 8 & b;
ret = ret << 8 & c;
ret = ret << 8 & d;


Og så argumenterer du for at bruge de binære operatorer -
mener du ikke de bitvise? Man kommer
ikke langt uden de binære operatorer :)

mvh Jonas

---

"Jonas Meyer" <a@b.c> wrote in message news:bsuhan$1jun$1@munin.diku.dk...
> Du mener vist
>
> ret = ret << 8 & b;
> ret = ret << 8 & c;
> ret = ret << 8 & d;

Ehm,

ret = ret << 8 | b;
ret = ret << 8 | c;
ret = ret << 8 | d;

Sådan må det vel være.
Beklager.

---

> > Du mener vist
> >
> > ret = ret << 8 & b;
> > ret = ret << 8 & c;
> > ret = ret << 8 & d;
>
> Ehm,
>
> ret = ret << 8 | b;
> ret = ret << 8 | c;
> ret = ret << 8 | d;
>
> Sådan må det vel være.
> Beklager.

Dette viser på klareste vis at Igor har ret Klar og overskuelig kode
frem for alt -- man kan altid optimere senere hvor det viser sig nødvendigt.

---

[ Per Pedersen ]

[ ... ]

> Du kan pakke de 4 bytes op i et longword,


Min kjemilærer pleide å si i slike situasjoner "joda, man kan til og
med lære en kanin å røyke, men hva skulle poenget med det være?"

[ ... ]


> char a, b, c, d = {0xFE,0xFE,0xFE,0xFE};
> long ret = 0x00000000;
>
> ret = a;
> ret = ret << 8 && b; // Skift 8 bit til venstre, og put den næste byte ind
> ret = ret << 8 && c; //
> ret = ret << 8 && d; //


_Takk_ for at du illustrerer hvorfor en slik "pakking" er en dårlig
løsning når ikke noe annet er kjent om problemet. En struct eller en
array vil være langt å foretrekke framfor dette svineriet.

Jeg kan se seks problemer[*] i de seks linjene over, hvorav en del er
direkte feil. _Fortell_ oss gjerne hva _du_ mener "løsningen" din
egentlig løser.

[*] 1. Feil måte å initialisere char-variablene på (python tillater
noe slikt, men ikke C).
2. For stor konstant for den respektive typen (char kan være
signed)
3. Feil operand (&& framfor |)
4. Bitmanipulasjoner av signed typer (det er bare dustete, gitt de
begrensningene som gjelder i språket)
5. Unødvendig antagelse om CHAR_BIT
6. Unødvendig (og gjerne gal) antagelse om at sizeof(long) == 4

[ ... ]


> Det kan godt virke lidt nørdet at bruge de binære operatorer, men
> det er utroligt hurtigt at udføre for processoren,


Speed gets you nowhere, if you are headed in the wrong direction.


> og en meget brugt teknik i assembler, og særligt til
> billedbehandling, hvor der dog sker en hel del mere smiden rundt med
> bits på kryds og tværs i registre og hukommelse.


Hvor var det jeg leste at man skal foretrekke den koden som forklarer
hensikten bak på den klareste mulige måten?

Bare det alene at du nevner "hurtig" over er en god nok grunn til å
avfeie forslaget ditt. Når man titter enda nærmere på det (og selv med
alle de rettelsene over), så er forslaget fremdeles feil for annet enn
et veldig snevert utvalg av problemer sett i lyset av en dårlig
kompilator.

Vær så god, neste.





ivr
--
<html><form><input type crash></form></html>