Punktoperator bei arithm. Berechnung?

.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

net 0

chr11 schrieb:

CPU_NCR0 .equ 0xF0xxxxx

...und was soll dieses 'xxxxx' bedeuten?

chr11 schrieb:

http://www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-64423&channelPage=%2Fep%2Fchannel%2FproductOverview.jsp&pageTypeId=17099

da steht dass es entwicklungskits von tasking und irgendwie so'n gnu-kram gibt. vielleicht sollteste mal im include-pfad der tools suchen...

chr11 schrieb:

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

ach so, als zusätzliche schwierigkeit für alle die dir helfen wollten. wär' ja sonst auch zu einfach gewesen

ob jetzt der Name so oder so ist ist doch egal? Ich wollte es doch nicht schwieriger machen. Wo ist der Unterschied ob da ein x oder ein y steht? Ich musste sie halt ändern.

xxxxx steht halt für irgendwelche Hex Zahlen. Sollte aber beim vorhergehenden 0xF klar geworden sein.

Inzwischen glaube ich wird der Compiler einfach die eigentliche Adresse mit dem Namen <CPU_Sonstwas> ersetzen ohne dass man das in den Source files findet.
Und das .I wird auch intern vom Compiler erkannt und bedeutet dass alle 32bit angesprochen werden. Im Quellcode ist davon leider WIRKLICH! nichts zu finden.
.I -> Integer bei 32bit CPU sind das 32bit
.B wäre dann z.B. nur ein Bit
Vielen Dank für die Hilfe und Unterstützung. Ich hab wohl das Kaliber dieses TC etwas unterschätzt.

net 0

chr11 schrieb:

Ich musste sie halt ändern.

du musst das nicht ändern. jedenfalls nicht, wenn du willst dass dein hilferuf erfolg hat. es könnte ja sein dass hier einer die gleiche toolchain benutzt wie du und dann hätteste schon längst die antwort. übrigens: die meisten hilfsbereiten user hier haben schnell keinen bock mehr, wenn du denen solche steine in den weg legst.

chr11 schrieb:

.I -> Integer bei 32bit CPU sind das 32bit
.B wäre dann z.B. nur ein Bit

...und woher weisst du das?

btw: oft kann man compilern auf der kommandozeile definitionen mitgeben. vielleicht steckt es in irgendeinem makefile oder dergleichen. wenn du alle dateien in allen verzeichnisse durchsuchst, die beim buildvorgang benutzt werden, wirst du sicher was finden.

camper

ich tippe darauf, dass irgendwo noch ein define existiert auf ein passendes union zwecks type punning. immerhin sind die klammern in NBX_BASE nicht paarig.

net schrieb:

du musst das nicht ändern. jedenfalls nicht, wenn du willst dass dein hilferuf erfolg hat. es könnte ja sein dass hier einer die gleiche toolchain benutzt wie du und dann hätteste schon längst die antwort. übrigens: die meisten hilfsbereiten user hier haben schnell keinen bock mehr, wenn du denen solche steine in den weg legst.

Das verstehe ich, ging aber aus Sicherheitsgründen leider nicht anders.

chr11 schrieb:

.I -> Integer bei 32bit CPU sind das 32bit
.B wäre dann z.B. nur ein Bit

...und woher weisst du das?
Das glaube ich weil ich eine ähnliche Anweisung mit .B gefunden habe. Dort wird aber nur ein Bit kopiert. Es müsste evtl sogar möglich sein jedes einzelne Flag (z.B. im Processor Status Word) einzeln anzusprechen. Also mit Namen. Habs aber noch nicht ausprobiert.

net schrieb:

btw: oft kann man compilern auf der kommandozeile definitionen mitgeben. vielleicht steckt es in irgendeinem makefile oder dergleichen. wenn du alle dateien in allen verzeichnisse durchsuchst, die beim buildvorgang benutzt werden, wirst du sicher was finden.

Ich weiß jetzt wo das alles herkommt. Die REGTC1796.cfg wird vom Build Prozess eingebunden. (Leider ohne dass ich die Datei wirklich finden kann. Wird aber per

_asm include

includiert)
Dort werden die Namen der Register definiert. Ich habe in den Headern lange nach den Definitionen für ein struct oder union gesucht. Da ist mir erst aufgefallen dass die REGTC1796 überall includiert wird aber nirgens zu finden ist. Im Endeffekt kommt es aber auf das gleiche heraus wie bei einer Assembler Equate (.equ) Anweisung. Und so wirds sicher auch gemacht.
Das .I muss ja wirklich ein Element sein. Das man aber nirgens finden kann. Ist wohl auch aus der REGTC1796.
Auch ein interessantes Beispiel:

#define USB_SRC6_SRR             ((T_Reg32 *) 0xF00E28E4)->bit13

Vielen Dank für die Hilfe und die Anregungen. Und sorry fürs nerven
Gruß
chr

.filmor

Assembler ist hier völlig irrelevant. Wenn das auf einem echten C-Compiler (und nicht irgendeiner Mutation) kompiliert, dann gibt es irgendwo eine union (ist hier imho das wahrscheinlichste), aber im C-Code, nicht auf Assemblerebene, denn da gehen, wie ich schon einmal gesagt habe, alle Typinformationen (und damit auch die Namen der Felder) flöten.
Ein möglicher Code wäre (nach meinen, ähnlich wie Assembler, rudimentären C-Kenntnissen):

union
{
    int I;
    unsigned int B:1;
} CPU_NCR0;