Punktoperator bei arithm. Berechnung?

Hallo, ich kann mir folgende Zuweisung nicht erklären, zumindest nicht das .I
Es handelt sich dabei um eine Adressberechnung mit anschließendem Schreibzugriff auf diese Adresse. Den Punktoperator kenne ich bei Element oder Methodenaufrufen. Dies ist hier aber beides nicht der Fall.
Hat vielleicht jemand eine Idee um was es sich hierbei handeln könnte?
Vielen Dank

#define BIOS_WriteX(id,value) \
( (*((NBX_BASE)+((NBX_OFS)*id))).I =(value) )

Swordfish

Zeig mal die definition von NBX_BASE und NBX_OFS.

Greetz, Swordfish

#define NBX_BASE (&(CPU_NCR0) CPU_NCR0 entspricht einfach einem Hex Wert, also der Adresse im Speicherbereich. (wird per equate zugewiesen)

#define NBX_OFS (0x00000100/4) ist im Prinzip nur eine hex Zahl

LordJaxom

chr11 schrieb:

#define NBX_BASE (&(CPU_NCR0) CPU_NCR0 entspricht einfach einem Hex Wert, also der Adresse im Speicherbereich.

Bist Du Dir da sicher? Auf einen einfachen Hexwert kann man keinen Adressoperator anwenden. IMHO müsste CPU_NCR0 eine Struktur sein, damit das ganze Sinn ergibt.

Javaner

chr11 schrieb:

#define BIOS_WriteX(id,value) \
( (*((NBX_BASE)+((NBX_OFS)*id))).I =(value) )

Nett von euch, mich von Zeit zu Zeit immer mal wieder
daran zu erinnern, warum ich mit C nichts mehr zu tun haben will.

Bin sicher, das geht jetzt aber in Assembler rein.
1230 CPU_NCR0 .equ 0xF0005240
nach der Zeilennummer wird der Hex Wert einfach mit dem Namen CPU_NCR0 assoziert. Imho steht daher CPU_NCR0 einfach für 0x0sonstwas

Javaner

Warum umbedingt eine Struktur?

#ifdef HugoEgon
#    define  CPU_NCR0 i
#else
#    define  CPU_NCR0 j
#endif

#define NBX_BASE (&(CPU_NCR0))

int main() {
  int i=1;
  int j=2;
  *NBX_Base = 42;
}

geht doch auch

.filmor

Auf Assemblerebene gibts gar keine Typen mehr. Irgendwo in den Headern MUSS eine Strukturdefinition für den Typ von CPU_NCR0 geben.

Das ist ja auch kein Typ. Wäre doch das gleich wenn man #define CPU_NCR0 0x0xxxxxxxx schreiben würde. Die .equ Anweisung vom Assembler kommt auf gleiche heraus.
Dann ist im Header nur noch define NBX_BASE (&(CPU_NCR0)) zu sehen.

Aber eigentlich verstehe ich eher das .I nicht. Könnte es denn sein dass es sich hier um eine Umwandlung von einem Integer auf einen Pointer handelt?
(*((NBX_BASE)+((NBX_OFS)*id))).I

.filmor

Der Typ VON CPU_NCR0! Und wie gesagt, der Assembler-Output bringt dir einen Dreck, wenn du in C arbeitest. Beim Kompilieren gehen ziemlich viele Informationen verloren. Lass mal nur den Präprozessor drüberlaufen und such dann diese Zeile.

net 0

NBX_OFS ist wohl nur eine konstante aber NBX_BASE könnte irgendwas in der art sein:

struct _laladumm
{
  int I;       
} laladumm;

#define NBX_BASE &laladumm

Swordfish

schrieb:

Aber eigentlich verstehe ich eher das .I nicht. Könnte es denn sein dass es sich hier um eine Umwandlung von einem Integer auf einen Pointer handelt?

Nein.

LordJaxom schrieb:

IMHO müsste CPU_NCR0 eine Struktur sein, damit das ganze Sinn ergibt.

IMNSHO hat LordJaxom - wie des öfteren Recht.

Leutz, wenn er uns schon nicht die Definition (bis zu einem verständlichen Level) geben will bringt das Rumgerate genau nix, bis vielleicht auf Spaß:

Javaner schrieb:

#ifdef HugoEgon
#   define  CPU_NCR0 i
#else
#   define  CPU_NCR0 j
#endif

#define NBX_BASE (&(CPU_NCR0))

int main( )
{
    int i=1;
    int j=2;
    *NBX_Base = 42;
}

net schrieb:

struct _laladumm {
    int I;      

} laladumm;

#define NBX_BASE &laladumm

Greetz, Swordfish

Es tut mir ja leid, aber es gibt nicht mehr. Ich hab auch alles abgesucht. Es ist genau so definiert wie ich es gepostet habe. NBX_BASE ist auch kein Struct oder sonstwas. (ausser es gibt sowas auf Assembler ebene von dem ich nichts weiß)
IMHO ist die .equ Anweisung vom Chiphersteller selbst und definiert CPU_NCR0 nur als neuen Namen für eines der Register. Damit man die HEX Adresse nicht immer hinschreiben muss.
Daher ist CPU_NCR0 eine Adresse und wird über die define von NBX_BASE auch so gesehen.
#define NBX_BASE (&(CPU_NCR0)
Etwas anderes gibt es nicht, kein Struct, sicher! Das ist ja nicht das einzige, das ist nur ein Beispiel. Das tritt hundertfach in der selben Art auf. Ich werte das jetzt einfach als Adressauflösung sehen. Mit der gleichen Anweisung kann man ja auch von der Adresse auslesen (nur ohne das = )
Danke
Gruß
chr

.filmor

Wie wärs, wenn du einfach mehr Code posten würdest?! Denn entweder du benutzt einen suspekten Compiler, der diese struct Typen eingebaut hat, oder du hast schlecht gesucht :p. Änder doch einfach mal das .I in .Z und poste hier die Fehlermeldung.

/edit: Übrigens, nochmal als Zusammenfassung:

CPU_NCR0 müsste eine Instanz eines structs (nicht ein struct selber sein).
NBX_BASE wäre demnach ein Zeiger auf dieses Objekt, sicherlich aber kein reiner Hexwert.
NBX_OFS ist ein normaler Integer, den Rest bewerkstelligt die Zeigerarithmetik. Du müsstest einen Unterschied sehen, wenn du den NBX_BASE und NBX_OFS Teil vertauschst.

Wären da nicht so viele bescheuerte defines, dann könntest du ohne weiteres den Code so umformulieren:

(NBX_BASE + NBX_OFS * id)->I = value;

Swordfish

, ich weiß ja nicht, ob du das noch liest oder schon aufgegeben hast, aber:

schrieb:

Es tut mir ja leid, aber es gibt nicht mehr.

Glaub' ich nicht.

schrieb:

NBX_BASE ist auch kein Struct oder sonstwas.

Doch.

schrieb:

ausser es gibt sowas auf Assembler ebene von dem ich nichts weiß

Wieso redest du die ganze Zeit über über Assembler!?

schrieb:

IMHO ist die .equ Anweisung vom Chiphersteller selbst und definiert CPU_NCR0 nur als neuen Namen für eines der Register. Damit man die HEX Adresse nicht immer hinschreiben muss.

Jetzt kommt erst der Witz: Register haben keine Adressen!

schrieb:

Etwas anderes gibt es nicht, kein Struct, sicher!

Siehe oben...

Wenn die Sorces nicht streng Geheim und nicht zu umfangreich sind, kannst sie mir ja mailen, dann schau' ich's mir an:
reiter.e [AT] gmx.net

Greetz, Swordfish

.filmor

Swordfish schrieb:

schrieb:

NBX_BASE ist auch kein Struct oder sonstwas.

Doch.

Nein, s.o. (es sei denn, du bezogst dich auf das "sonstwas" ;))

net 0

Swordfish schrieb:

Jetzt kommt erst der Witz: Register haben keine Adressen!

äääh, das kann man so allgemein nicht behaupten. es gibt sogar cpus bei denen man die internen register über speicherzugriffe erreichen kann, von irgendwelchen chips mit memory-mapped i/o ganz zu schweigen.

btw: wenn das für 'nen normalen compiler sein soll, dann ist NBX_BASE mit sicherheit die adresse einer union, struct oder class.

Leider kann ich nicht mehr angeben als das was ich bereits getan habe. Die Source Files per email zu verschicken würde fast jeden Server überlasten geschweige denn dass ich es natürlich auch nicht dürfte. Neu kompilieren kann ich es auch nicht und Schreibzugriff habe ich auch nicht. Es geht mir nur darum es zu verstehen warum man das so schreiben muss:

#define NBX_BASE (&(CPU_NCR0)
#define BIOS_WriteX(id,value) \
( (*((NBX_BASE)+((NBX_OFS)*id))).I =(value) )

Swordfish schrieb:

Jetzt kommt erst der Witz: Register haben keine Adressen!

Und natürlich haben Register Adressen. Jedenfalls wenn man mal nicht auf OS Ebene denkt sondern auf Hardware Ebene. Das ist eben die Schnittstelle zwischen der C-Software und der CPU selbst.
CPU_NCR0 ist ein Register in der CPU und hat daher auch eine Adresse!!!
NBX_BASE ist dann ein Pointer auf diese Adresse damit man mit Schreib und Lesefunktionen darauf zugreiffen kann.
NBX_OFS wird gebraucht um das richtige Register zu bekommen, da es bei weitem nicht das einzige ist. Das eigentliche Register wird also erst berechnet.

.filmor

chr11 schrieb:

Neu kompilieren kann ich es auch nicht und Schreibzugriff habe ich auch nicht. Es geht mir nur darum es zu verstehen warum man das so schreiben muss:

#define NBX_BASE (&(CPU_NCR0)
#define BIOS_WriteX(id,value) \
( (*((NBX_BASE)+((NBX_OFS)*id))).I =(value) )

Genau das ist bereits geklärt. Du brauchst dafür nicht großartig irgendworan rumzubasteln, du musst nur alle Header durchgehen (vielleicht werden auch noch includes von irgendwelchen Buildskripten reingeschrieben!) und schauen, welchen Typ CPU_NCR0 hat. Solange du keine Deklaration lieferst, die deine Ansicht untermauert, hast du leider Unrecht ;).

chr11 schrieb:

Swordfish schrieb:

Jetzt kommt erst der Witz: Register haben keine Adressen!

Und natürlich haben Register Adressen. Jedenfalls wenn man mal nicht auf OS Ebene denkt sondern auf Hardware Ebene. Das ist eben die Schnittstelle zwischen der C-Software und der CPU selbst.
CPU_NCR0 ist ein Register in der CPU und hat daher auch eine Adresse!!!

Die Begründung ist recht schwach. Übrigens, zumindest von meinen bescheidenen Assemblerkenntnissen weiß ich, dass Register direkt über ihren Namen angesprochen werden. Selbst wenn dieser in einen Opcode übersetzt wird, hat er doch ausgesprochen wenig mit einer normalen Speicheradresse gemein.
Für welche Architektur ist das eigentlich? Möglicherweise hat die ja so eine Übersetzung von Speicherbereichen (was allerdings für das Grundproblem völlig unerheblich ist. CPU_NCR0 ist mit ziemlicher Sicherheit ein Objekt mit einem int(?)-Member namens I)

@filmor: Danke das hat mir jetzt schon mal weiter geholfen, anscheindend bin ich zu blind, aber da ich auch mit Windows Grep nichts anderes finde wundert mich das eben. (nichts ausser

CPU_NCR0 .equ 0xF0xxxxx

, aber das hab ich ja schonmal gepostet)
Werde mich mal weiter auf die Suche nach der Antwort begeben.
Übrigens, um den hier gehts.
http://www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-64423&channelPage=%2Fep%2Fchannel%2FproductOverview.jsp&pageTypeId=17099

PS: die Namen und Werte der Register habe ich natürlich abgeändert