[elektro] C mégegyszer (SWITCH)

[hg12345]

Hi!

A minden elismerésem a Tiétek! 

De a PC-s készülékekkel kapcsolatban vannak fenntartásaim.
Ezzel kapcsolatban egy kérdés felmerült bennem, az EMC vizsgálatban a készülékek minősítésekor A,B,C,D tudott? 
Egy normál ipari készülék eseten a B még elmegy, de az A az igazi.
Ez esetben egy nemesfém hőelem esetén zavarok hatására a készülék nem változtatja meg a mérést se, ez feszültségben 6-11uV.


Meg egy kérdés milyen fordítót használtok, a teljes forrást lista szinten fordítjátok vagy részenkét és linkerelitek? Az utóbbi esetben nincs olyan fordító akár 64bites se ami megfelelő optimalizáslát tud végrehajtani. mert úgye a linker az az csak linker.....

Hát nagyon távolra mentünk a kérdésemtől.

 Üdv


> Hi! Nincs probléma.  A vicc szakállas de még mindig jó. Ugyan még
> nem írtam csoportban és nagy méretű architekturális eszközökre
> programot, de ami kicsiben is biceg az nagyban se lehet jó.

Nem akarlak en meggyozni, de van itt sok 10000 C sor.
Beagyazott rendszerekben meg PC-bol epitett celgepekben futo programok.
Evekig futnak kikapcsolas, ujraindulas nelkul. 7 ember sokevi munkaja.
C-ben van irva es nem nagyon talalsz bennuk goto-t.
A hibakezeles az egyetlen, ahol hasznaljuk.
(A cimkek 90%-a error, error_ret, error_out, kifele meg hasonlok.
Egy fuggvenyben nagy switch, minden agban hiba vizsgalatok,
es a fuggveny vegen egy helyen kiiras, lekezeles.)

> Lehet növelni a platform minden alapvető méretét (memória és sebesség)
> ettől még a program nem fog másképp futni rajta. Egy nagy
> megbízhatóságú eszköz (architektura) egészen más programozási
> technikát igényel, én eszerint programozok.

Ettol meg lehet C-ben strukturaltan programozni, sot.

> Szerintem az a kód jó
> ami rövid és tömör lehetőség szerint a kód csak egyszer szerepel
> benne. A javítás is ezen a legegyszerűbb. Hiába van optimalizáció
> mivel a GCC linkere olyan buta mint egy aranyhal, ezért csak egy
> forrásban tud valami optimalizációt elvégezni, így kicsi az esély
> arra hogy egy összetett programban minden program részletet a
> helyére tegyen.

A linkernek nem feladata az optimalizalas.
A fordito, meg jol optimalizal.

> Arról nem is beszélve, hogy csak olyan minőségű
> kódot tud gyártani mint aki macro-zta....

Egy forditoprogram nem macro. Akik 8 bites kontrollerekbol
nezik a vilagot, azok nem sokat tudnak a forditoprogramok optimalizalasarol.
Egy rendes 32 bites processzornal pl. pentium, honapokat fogsz eltolteni,
mire kezzel elered egy rendes colmpiler kodjat.
(Van kezzel optimalizalt DSP kodunk, kesleltett ugrassal, pipeline-al stb.
Jó jatek volt. Egyszer. )

> Nem akarok pluszban
> 1-2% teljesítményt kicsavarni a kontrollerből, és memória hiányom
> sincs, a magas szintű (macro) nyelvet a különböző kommunikációs
> felületek későbbi implementálása miatt erőltetem.

En a kicsik kozul utoljara egy Hitachi H83664-es nyolcbites kontrollert
hasznaltam.
Sok helyen ugyan az a forras fordul ra, ami fut PC-n es 32 bites ARM-on is.
Az utasitaskeszleterol elkepzelesem sincs :)

Gábor
----------------------------------------------------------------
Ábrahám Gábor                           http://cdtransport.atw.hu/
7+ Számítógép Hálózati Kft.             Tel : (06-1) 248-3214
1118, Budapest, Homoród u. 17.          Fax : (06-1) 248-3216

-----------------------------------------
          elektro[-flame|-etc]