PureBoard

Frohe Weihnachten,

ich bin gerade etwas verwirrt (vermutlich, weil ich mich heute mit sowas nicht befassen sollte^^):
Weiso haben eigentlich Pointer auch ein Vorzeichen.

Negative Adresse gibt es nicht, und auch wenn intern die auch bei $90909090 (unter 32Bit) die richtige Adresse angesprungen wird, so gibt es in PureBasic ein Problem, wenn man es mit der Adresse $70707070 vergleichen würde. Ich bin darauf gestoßen, weil ich eigentlich eine Schleife machen wollte der Art: Wenn nun aber die höhere Adresse über $7FFFFFFF liegt, wird diese negativ, und die Schleife fängt garnicht erst an.

Nachdem ich in den ASM-Code geguckt habe, sehe ich das beim If in beiden Fällen mit JGE (Greater or Equal) rausgesprungen wird, obwohl ich gedacht hätte das man bei Pointern dann JAE (Above or Equal) benutzt.

Bedeutet das jetzt, das so manche Codes nicht mehr funktionieren würden, wenn die Speicheradresse wirklich mal über den 2GiB liegen würde?

STARGÅTE hat geschrieben:Frohe Weihnachten

ebenfalls

STARGÅTE hat geschrieben:Weiso haben eigentlich Pointer auch ein Vorzeichen

Weil man mit Pointern nicht rechnet. Soviel zum Grundsatz.

Aber wie so immer gibt es Ausnahmen von der Regel (etwa um Distanzen im Speicher zu ermitteln)
Da ist -zugegeben- PB etwas neben der Spur. Intern wird nicht zwischen Pointern und Integern unterschieden. da kommt man dann nicht umhin, selbst ein kleines ASM-Inlay hinzulegen.

Das ist ein schlechtes Argument. Man nimmt keinen Pointertyp um Distanzen im Speicher zu messen. Eigentlich sollten Pointer immer vorzeichenlos sein.
Außerdem rechnet man mit Pointern sehr wohl. Man addiert eine Distanz drauf oder zieht sie ab um zur nächsten Speicherstelle zu kommen. Und Vergleichsoperatoren für Pointer zu nutzen ist durchaus üblich. Lediglich Mulitplikationen und Divisionen mit Pointern machen keinen Sinn, genau wie alle anderen höheren Operationen.

Da hab ich auch noch garnicht so wirklich drüber nach gedacht, aber bis
auf die neusten Variablentypen .u und .a sind ja alle anderen Vorzeichenbehaftet,
das gilt ja dann auch für Integer und Pointer. Das aber Pointer gerade zum
schnelleren Zugriff auf Speicherbereiche benutzt werden, also damit Rechungen
passieren, würde das tatsächlich zu Problemen führen.

32-Bit Anwendungen kommen aber unter Windows nicht über 2GB, gibt es solch
eine "künstliche" Grenze auch für Linux und Mac? Wenn nicht, müsste das
umgehend mal im englischen Forum mit Fred und Freak diskutiert werden. Das
würde die möglichkeiten von PB drastisch einschränken bis zu einem Update.
Aber in der Praxis hab ich damit noch keine Probleme gehabt ... doch bisher
war ich auch z.B. nur unter Windows und 32-Bit aktiv.

Und wie siehts bei 64-Bit Anwendungen aus? Wenn der eh nur bei 2^64/2 liegt,
wäre das so ok ... aber wenn nicht ... Englisches Forum

MFG PMV

Also ich habs jetzt mal spaßes halber probiert, einen Pointer zu erzeugen der über 2^31-1 liegt, es funktioniert einfach nicht:

33'423'392
133'431'328
233'439'264
333'447'200
433'455'136
533'463'072
633'471'008
733'478'944
833'486'880
933'494'816
1'033'502'752
1'133'510'688
1'233'518'624
1'333'526'560
1'433'534'496
1'533'542'432
1'633'550'368
1'733'558'304
0
0
0

Scheinbar kann man/ich doch rechts beruhigt an die Sache gehen.
Obwohl ich ja immer dachte 32Bit System können 4GB nutzen, gerade weil Pointer eigentlich unsign sind.

Unter einem 32-Bit Betriebssystem haben einzelne Prozesse normalerweise nur die Möglichkeit Speicher bis zu 2 GB zu allozieren. Insgesamt können aber mehrere Prozesse zusammen mehr als 2 GB nutzen. Mit dem richtigen 32-Bit Linux-Kernel kann man insgesamt auch mehr als 4 GB Arbeitsspeicher ansprechen. Das weiß ich aber nur vom Hören-Sagen. Eine verlässliche Quelle dazu habe ich gerade nicht zur Hand.

Dennoch finde ich es weiterhin problematisch, dass Pointer unter PB unsigned sind. Und zwar wegen den oben schon genannten Problemen. Aber warten wir mal die Feiertage ab. Dann wird sich bestimmt auch noch der ein oder andere fachkundige PB-ler dazu äußern.

NicTheQuick hat geschrieben:...dass Pointer unter PB unsigned sind

Verschrieben? Sie sind signed! Zumindest in der Darstellung nach aussen und in mathematischen Berechnungen, weil sie von PB wie Integer behandelt werden. Funktionieren tun sie aber auf alle Fälle, weil dem Prozessor die Definition von "signed" und "unsigned" völlig am A..... vorbeigeht.

Der Test funktioniert unter Windows nicht. Prozesse haben
nen 2GB limit, und unter 64-Bit ... wer hat heute schon über 8 EiB?
Das müsste mal jemand mit Linux oder Mac testen. Und dann
müsste da auf nen Offset zugegriffen werden, um nen IMA zu erhalten
bei negativen Speicheradressen


MFG PMV

PMV hat geschrieben:um nen IMA zu erhalten bei negativen Speicheradressen

Speicheradressen sind niemals Negativ, auch in PB nicht, egal wie das erste Bit in der Ansicht
interpretiert wird, hat dies jedoch keinerlei einfluss auf den richtigen Wert im Speicher.
Distanzen addieren usw. verfälscht zwar das visuelle Ergebnis, aber die Speicherstelle bleibt
korrekt, also einfach ignorieren und gut , mathematisch korrekte Ergebnisse anzeigen ist
hierbei doch nicht nötig.

Die CPU nutzt den 32- oder 64- Bit Wert, so wie er da steht und beachtet sowas wie Vorzeichen-Bit
sowieso nicht, weil das ja keinen Sinn machen würde. Wer unbedingt Speicherstellen darstellen möchte,
muß diese natürlich Maskieren.

Speicheradressen sind niemals Negativ, auch in PB nicht, egal wie das erste Bit in der Ansicht
interpretiert wird, hat dies jedoch keinerlei einfluss auf den richtigen Wert im Speicher.

Das ist natürlich richtig. Das hab ich ja auch am Anfang geschrieben, nur leider hab ich ab und zu halt sachen wie: in meinen Codes weil es einfach handlicher ist als: Das die richtige Stelle angesprungen wird, weiß ich ja, nur leider könnte der Vergleich *CurrentPointer < *EndPointer irgendwann nicht hinhauen, weil für PB *EndPointer negativ sein könnte.