[LUGA] Mit freundlicher Unterstützung von:
OCG

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bitschusterei (was Re: [luga] Re: [lll]: OT: char, byte and octet)



Hallo !

On Thu, 6 Mar 2003, Bernd Petrovitsch wrote:

> >Ich verwends noch *ggg* auch wenn ich's lieber bleiben lassen würde, aber 
> >beim programmieren einer JavaCard schummelst versuchst noch jeder bit 
> 
> Hmm, wieviel Bytes Code brauchst du, um wieviele Bits einzusparen?
> Geht es da um Bits im RAM oder ROM?
> Hast du da seriöse, konkrete Werte?
> Es macht je wenig Sinn, 5k Code zu verbraten, um im ROM 3k Daten
> einzusparen.

Doch, wenn du zwar viel ROM aber nur sehr wenig RAM oder EEPROM hast!
Sicher, auf einem herkömmlichen System hat das keine Relevanz (mehr)

> >einzusparen. Auch wird auf SIM-Karten vieles noch BCD-Kodiert.
> 
> Hat das einen besonderen Grund, warum das so sein sollte? Mir fällt 
> beim besten Willen keiner ein. Das einzige ad hoc ist:
> -) COBOL-Erbe: man kann Fließkommadezimalzahlen einfach darstellen.
> Und aus wars.
> Was spricht dagegen:
> -) Ich kenne keine Prozessor, der für BCD-Code gebaut wurde (ja, der 
>    x86 hat lustige, so gut wie nie verwendete Asm-Befehle, aber der 
>    verwendet BCD nicht "native").
> -) Ich verschwende grob gerundet 6/16 des Speichers.
> Also?

Das hat einen ganz simplen Grund: Die GSM Spezifikation (und die ist ja 
schon von 1995!) verlangt einfach, dass zb. ein PIN oder ein eintrag im 
Telefonbuch BCD-Kodiert abzulegen ist. Aber auch sonst leg ich oft mehrere 
Boolean-Werte als bits in Bytes ab (Java verbratet sonst für einen Boolean 
ein Byte - oder gar einen Short). Ich hab auf den Karten zwar 14k EEPROM 
(oder 64k ROM), aber nur wenige Bytes shared RAM, bzw. 200 Byte Stack, 
keinen Garbadge-Collector und als Datentypen nur byte, short, und 
Object-Pointer. Big Dezimal, Float, Char oder gar String - wer braucht 
denn sowas ;-(

Selbst auf Java4Mobile (also zb. diese Handy-Games zum downloaden) hast du 
nicht mehr Datentypen und max 64k pro Package aber immerhin mehr RAM (i.a. 
so ein paar hundert kb) auch muss man sich dort keine Gedanken machen, ob 
die Variable jetzt in ROM, EEPROM oder RAM abgelegt werden soll.

Ich hab auch schon geglaubt, dass sich sicher keiner mehr mit Bits und 
64k-Beschränkungen herumärgern muss, aber bis auf Chipkarten 32bit 
Prozessoren und 1MB FLASH verbaut werden wird noch einige Zeit vergehen.

Also besteht für die Krankenkassenkarte ja noch eine Chance. In 
VisualBasic unter WindowsME programmiert werden sie sie ja dann doch
hinbekommen! Wobei... immerhin kann man ja auf der Chipkarte den 
Blue-Screen gut verstecken *ggg*

Liebe Gruesse, Schroettner Robert
|   Schroettner Robert
|   IT-Services
|   Eurodata Datenverarbeitungsdienst Ges.m.b.H.
|   Tel:  +43-1-7747076-51                    __   _
|         +43-664-4345798                    / /  (_)__  __ ____  __ 
|   Fax:  +43-1-7747076-12                  / /__/ / _ \/ // /\ \/ /
|   WWW:  http://www.ednet.at              /____/_/_//_/\_,_/ /_/\_\
|                                                    TUX for President
|   EURODATA - WIEN - PRAG - BRUENN - BUDAPEST




powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010