---

Hej NG.

Kan man sige noget om om Ansi-C floating point (32 bits) er langsommere end
32 bit longs i Keil's uVision compiler ?
Hvad med generelt (compiler uafhængigt) ?

--
mvh/rg. From The Sum of all Fears:
Christian [In a Nuclear Arms depot in Russia, during an inspection]
Bill Cabot: What's that man's T-Shirt say?
Depot Worker: Oh...[laughs]... I am a bomb technician, if
you see me running, try to catch up!

---

Christian B. Andresen skrev:
> Hej NG.
>
> Kan man sige noget om om Ansi-C floating point (32 bits) er langsommere end
> 32 bit longs i Keil's uVision compiler ?
> Hvad med generelt (compiler uafhængigt) ?
>

Nej, C standarden siger ikke noget om hastighed/performance, så hvad der
er hurtigst er afhængig af compiler og processor.
Generelt kan man sige at hvis processoren ikke har support for floating
point indbygget, enten som en co-processor eller som processor
instruktioner, så er floating point meget langsommere end 32-bit long's.
Floating point er sjældent hurtigere end fix point beregninger.

/b

--
Bertel Brander, author of Wain, a free text editor for windows:
http://home20.inet.tele.dk/midgaard/program.htm

---

Christian B. Andresen skrev:

> Kan man sige noget om om Ansi-C floating point (32 bits) er langsommere end
> 32 bit longs i Keil's uVision compiler ?

uVision er ikke en compiler, men et IDE (Integrated Development Enviroment)
dvs. softwaren "omkring" compileren. Forskellen mellem afviklingshastigheden
mellem de to typer er afhængig af compileren og processoren - mest den sidste.
Keil er kendt for deres 8051 compilere. 8051 er en ren 8 bits processor, uden
matematik-processor. Den afvikler 32 bits integer langt hurtigere end 32 bits
floats. Hvis man har brug for mange beregninger, er 8051 ikke den rigtige
processor.


Ivar

---

"Ivar" <did@[nozpam]oncable.dk> wrote in message
news:3e66634c$0$153$edfadb0f@dtext01.news.tele.dk...
>
> Christian B. Andresen skrev:
>
> > Kan man sige noget om om Ansi-C floating point (32 bits) er langsommere
end
> > 32 bit longs i Keil's uVision compiler ?
>
> uVision er ikke en compiler, men et IDE (Integrated Development
Enviroment)
> dvs. softwaren "omkring" compileren.

Det ved jeg godt.

> Forskellen mellem afviklingshastigheden
> mellem de to typer er afhængig af compileren og processoren - mest den
sidste.
> Keil er kendt for deres 8051 compilere. 8051 er en ren 8 bits processor,
uden
> matematik-processor. Den afvikler 32 bits integer langt hurtigere end 32
bits
> floats.

Vil det så sige at tallet 56.123456 ville være hurtigere at arbejde med hvis
det var gemt i en long som
56123456 ?

> Hvis man har brug for mange beregninger, er 8051 ikke den rigtige
> processor.

Nej, men HW afdelingen har valgt hardwaren, så der er jeg bundet. Det går
også fint, men efter hånden som projektet vokser
til: real-time kerne, 200 k kode og 25 k ram. kunne det være en fordel at
optimere projektet.


--
mvh/rg. From The Sum of all Fears:
Christian [In a Nuclear Arms depot in Russia, during an inspection]
Bill Cabot: What's that man's T-Shirt say?
Depot Worker: Oh...[laughs]... I am a bomb technician, if
you see me running, try to catch up!

---

> Vil det så sige at tallet 56.123456 ville være hurtigere at arbejde med
hvis
> det var gemt i en long som
> 56123456 ?

Kan du klare dig med heltal så gør endelig det, men hvis du både skal
håndtere meget små og meget store tal kan floats være rare.
En anden ting ifb. med non-float harware er at første gang du skriver et
kommatal eller ordet float , får du linket hele float-biblioteket med ind
(afhængig af hvor snu linkeren er). Ofte adskillige kb.
Kig i lst filen og find en udregning hvori der indgår nogle floats og ints,
og se hvor meget kode der genereres. Du vil finde en stribe kald til
_unsigned_long_to_float, _float_to_signed_long _float_mul etc etc.

tpt

---

Christian B. Andresen skrev:

> > uVision er ikke en compiler, men et IDE (Integrated Development
> Enviroment)
> > dvs. softwaren "omkring" compileren.
>
> Det ved jeg godt.

Så burde du have fortalt hvilken processor compileren var til. En oplysning
om enviroment er der ikke megen relevant information i.


> Vil det så sige at tallet 56.123456 ville være hurtigere at arbejde med hvis
> det var gemt i en long som
> 56123456 ?

Helt sikkert (hvis vi taler 8051). Til gengæld er det noget langsommere for
programmøren at arbejde med. C giver ingen hjælp til fix-point beregninger.
Addition og subtraktion er problemløst, men ved multiplikation og division
flytter kommaet sig.
fx: 10.0 * 10.0 = 100.00
Ofte placerer man kommaet ved 2^n i stedet for 10^n som i dit og mit
eksempel. Så kan man bruge den "billigere" shift, i stedet for mul og div,
når kommaet skal flyttes på plads.


Ivar

---

> Helt sikkert (hvis vi taler 8051). Til gengæld er det noget langsommere for
> programmøren at arbejde med. C giver ingen hjælp til fix-point beregninger.
> Addition og subtraktion er problemløst, men ved multiplikation og division
> flytter kommaet sig.
> fx: 10.0 * 10.0 = 100.00
> Ofte placerer man kommaet ved 2^n i stedet for 10^n som i dit og mit
> eksempel. Så kan man bruge den "billigere" shift, i stedet for mul og div,
> når kommaet skal flyttes på plads.

Fixedpoint matematik er da ikke langsommere for programmøren, det er
bare et spørgsmål om tilvænning. For nogen år siden, da det kunne betale
sig at lave heltalsgymnastik fremfor at bruge floats/doubles var vi
mange der bl.a. lavede 3D-engines der arbejdede 100% med fixedpoint. Det
er rigtigt, at det tager lidt tid i opstarten, men så snart at man
f.eks. har skrevet sine linear-algebra-biblioteker i fixedpoint, så er
der ikke så meget mere fixedpoint at tænke på.

.... 0g som du så ganske rigtig pointerer så er det smart at indele efter
2^n så man kan bruge shifts.