Für dieses Forum muß Javascript im Browser aktiviert werden!
Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C2 Quellcode formatieren: <code>Quellcode</code> ASM Quellcode formatieren: <asm>Quellcode</asm> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! > Hallo Rolf, > > > Das finde ich aber keine saubere Lösung denn dann muß ich wieder unteschiedliche Fehlerprüfungen > > vorsehen. Irgendwie kannst Du dich nicht mit dem Gedanken anfreunden, die Funktionen zu vereinheitlichen... > > Es wäre nicht mal ein Laufzeitproblem da Fehler ja eigentlich nur selten bis garnicht auftreten dürften. > > Unterschiedliche Fehlerabfragen machen zudem Programm unübersichtlich... denk auch mal an die, > > die diese Funktionen verwenden werden... Je schwieriger und differenzierter die Anwendung um so > > fehlerträchtiger ist der Einsatz. Mach doch bitte alle Fehlerfälle mit der neuen Funktion.... > > Die Lösung ist "sauber". Und die Funktionen sind einheitlich. Nur gibt es eben kleine > feine Unterschiede. > > Die Array-Lese-Funktionen(Arrays & String) müssen nicht in lasterr schreiben. > Was soll man da für Zusatzinformationen reinpacken, außer die, die man schon > vom Rückgabewert erhält ? > lasterr ist nur für erweiterte Fehlermeldungen gedacht. > > > Hm.. kann der C164 das nicht? das ging ja schon auf dem 68000er... > Der C164CI ist ein 16Bit-Controller ! > Der Datenzugriff erfolgt immer 16-Bit-Weise. Darum darf hier niemals eine > ungerade Adresse zur Adressierung benutzt werden. > Der Ausnahmefall: Der Byteweise Zugriff (In ASM z.B. mit MOVB). > > > Naja gut.. das scheint bei Intel und Derivaten so üblich zu sein... es bremst ja auch ungemein... > ?? Warum sollte dies bremsen ? > > > Allerdings kann Deine Aussage nur für den operativen Speicher in der CC2 zutreffen da der Zugriff > > bei externen eeproms sequenziell ist....immer... auch wenn nur ein Byte gelesen wird. Von da her ist das > > also egal mit den Adressen weil das eeprom sowas wie ein Speichermedium und kein Hauptspeicher ist. > > Ungerade Adressen sind also definitiv kein Problem im Eeprom wenn der Pagebreak ok ist. > > Ich sag ja nur, daß es zum guten Stil gehöre, und nicht verboten sei. > Wie jemand den Speicher nutzt, ist jedem selbst überlassen. > > > > Beachte, daß bei writebyte() im Fehlerfall lasterr nicht geschrieben wird und > > > geterr() auch keinen Fehler anzeigt, da writebyte nur true oder false zurückgeben kann > > > > Pffff..... irgendwie müssen wir das doch mal grade ziehen können... > > ?? Es gibt, wie bei den Array-Lese-Funktionen keine relevanten Daten für die > erweiterte Fehlererkennung mit lasterr. Darum wird das nicht dort hineingeschrieben. > > > Demnach werden Strings über referenzes (Adresspointer) adressiert, alles andere als Stackwert. > > Dann hab ich das mit dem Seiteneffekt evtl. bei Stringvariablen gesehen.. na egal... > Bei Strings und Arrays wird die RAM-Adresse auf den Stack geladen. > > > Es dürften dann auch noch ein Unterschied zwischen Lauzeitstrings und Stringconstanten geben > > da letzteres ja im Flash landet und nicht im Betrieb überschrieben werden kann. > > Richtig. Hier gibt es einen Unterschied. Man kann z.B. keine Stringkonstanten einer > Funktion übergeben, da diese in einem anderem Segment stehen. > > > Wäre es dann möglich, die Parameter für readbyte, readint und read long (die drei Problemfunktionen) > > auch als arrays auszulegen? Dann wäre zwar a=readbyte(); nicht möglich > > aber ein readbyte(a) müste doch gehen. So hatte ich das mal vor und deswegen wollte ich mal > > neue 3 Funktionen einbringen (getabyte , getaint, getalong) die das jetzige Verhalten haben sollten. > > Man kann das definieren.. getax ist Funktionen mit Rückgabe, readx sind Unterprogramme die nur Fehlerwerte > > returnen und die gelesenen/geschriebenen Werte per "call by reference/array" übergeben. > > Das würde einige konzeptionelle Probleme entschärfen. > > Möglich wäre es, jedoch benötigt man dafür eigene Datentypen, was das Ganze dann sehr umständlich > und sogar langsam macht ! > > MfG André H.
