wie erstelle ich einen Speicherbereich, und verschiebe diesen in einen anderen ?

[Jens Kallup]

Hallo

wie kann ich ein 4x4 Feld an Daten erstellen,
das ich dann in eine andere Speicherposition
verschieben kann ?

Für Informationen in 386er code wäre ich dankbar.
also 16-Bit Intel

Jens

[Peter J. Holzer]

On 2021-06-18 13:06, Jens Kallup <kallu...@web.de> wrote:
> wie kann ich ein 4x4 Feld an Daten erstellen,
> das ich dann in eine andere Speicherposition
> verschieben kann ?

Was meinst Du mit "verschieben"? Kopieren?

> Für Informationen in 386er code wäre ich dankbar.
> also 16-Bit Intel

i386 ist 32-Bit. 8086 ist 16-Bit.

Die Syntax hängt vom verwendeten Assembler ab. Welchen verwendest Du?

Wenn ich z.B. mein altes Turbo Assembler Manual aus den 1980ern
ausgrabe, dann finde ich dort

DW
Function: Defines a word-size (2 byte) data area
Syntax: [name] DW [type PTR] expression [, expression]

Für 16 (4*4) uninitialierte 16-Bit-Werte mit Name "feld" würde man also
schreiben:

feld DW 16 DUP(?)

Wenn die die Werte 1, 2, 3, 4, ..., 16 haben sollen entsprechend

feld DW 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16

hp

[Jens Kallup]

Hallo Peter,

ich möchte eine Art Bootloader schreiben (ja ich weiß,
das gibt es alles schon, aber so zum Eigenen verstehen).

Ich möchte gerne ein paar Sektoren einlesen, und diesen
Speicher dann an eine andere Stelle als die Bootloader
Adresse verschieben also noch unter dem 1 MB.

Wenn ich das geschafft habe, möchte ich gerne diesen Code-
bereich ausführen, um dann evtl. Text darstellen.

Wenn ich das geschafft habe, möchte ich gerne auf 32-Bit
umschalten und dort weiter machen.

Das muss jetzt kein komplettes System werden, einfach nur
mal so als Education Projekt.

Ist sowas mit den NASM möglich ?

Gruß, Jens

[Steffen Christgau]

On 18.06.2021 15:06, Jens Kallup wrote:
> wie kann ich ein 4x4 Feld an Daten erstellen,
> das ich dann in eine andere Speicherposition
> verschieben kann ?

Wie Peter schon schrieb... Aber wenn du die Daten initialisieren willst,
musst du wissen/festlegen, wie du in deiner Anwendung nachher auf die
2D-Daten zugreifen willst. Oder anders: Wie ist das interne Format?
Speicherst du die Daten des 2D-Feldes zeilenweise im linearen Speicher
ab oder spaltenweise? Ersteres ist in C üblich und IMO verbreiteter,
letzteres bspw. in Fortran. Stichworte für Google: row-major und
column-major. Letztlich ist das aber Anwendungsfrage.

Das "Verschieben" oder besser Kopieren (so verstehe ich dich hier) ist
nicht mehr als ein memcpy. Das kannst du über eine Schleife selbst
machen oder über bspw. über die String-Befehle. Aus dem Kopf z.B. so:

MOV CX, Anzahl_Elemente_im_Feld
MOV SI, Quellfeld
MOV DI, Zieladresse
CLI
REP MOVSW

Gruß, Steffen

[Jens Kallup]

Hallo Steffen,

Danke für Deine Informationen.
mit REP MOVSW ...

werden damit SW - also String Word - 2 Bytes kopiert ?
Bei geraden Feldern ist das dann schneller als immer
nur 1 Byte zu kopieren.
Aber bei nicht linearer Größe - ist da SB vorzuziehen ?

Gruß, Jens

[Peter J. Holzer]

On 2021-06-19 10:49, Jens Kallup <kallu...@web.de> wrote:
> ich möchte eine Art Bootloader schreiben (ja ich weiß,
> das gibt es alles schon, aber so zum Eigenen verstehen).

Ein Bootloader war interessanterweise auch eines der ersten Programme,
die ich seinerzeit in 8086-Assembler geschrieben habe (ich hatte zwei
Betriebssysteme und musste immer mit fdisk die Boot-Partition ändern,
wenn ich das andere booten wollte - also habe ich einen Bootloader mit
Auswahlmöglichkeit geschrieben).

> Ich möchte gerne ein paar Sektoren einlesen, und diesen
> Speicher dann an eine andere Stelle als die Bootloader
> Adresse verschieben also noch unter dem 1 MB.

Warum liest Du die nicht gleich an der Stelle ein, wo Du sie haben
willst? (Nicht, dass es schwierig wäre, ein paar Bytes zu kopieren, aber
mir erschließt sich der Sinn nicht). Ok, kann sein, dass der sekundäre
Bootloader (der in der Boot-Partition) erwartet, an einer bestimmten
Adresse zu starten, das habe ich nicht mehr so genau in Erinnerung. Das
ist allerdings ohnehin nur von Bedeutung, wenn Du den auch verwendest,
was ...

> Wenn ich das geschafft habe, möchte ich gerne auf 32-Bit
> umschalten und dort weiter machen.

... hiermit im Widerspruch steht. Der Secondary Bootloader erwartet
sicher auch, im Real-Mode zu starten. Wenn Du im Bootloader schon auf 32
Bit umschaltest, brauchst Du ein Betriebssystem-Image, das erwartet, in
diesem Modus gestartet zu werden.

> Ist sowas mit den NASM möglich ?

Ich habe nie mit NASM gearbeitet, aber soweit ich weiß, kann der 16-,
32- und 64-Bit-Code erzeugen und eine Vielzahl von Binary-Formaten,
darunter auch Raw Binary. Sollte also alles können, was man für einen
Boot-Loader braucht.


PS: Ich beziehe mich oben auf das alte Boot-Loader/Partititionssystem
aus den 80er-Jahren. Mit UEFI ist alles anders.

hp

[Steffen Christgau]

On 19.06.2021 13:08, Jens Kallup wrote:
> werden damit SW - also String Word - 2 Bytes kopiert ?

Siehe Manual zu den Instruktionen. Aber ja, ...SB = Byte, ...SW = Word
(16 Bit), ...SD (Double Word = 32 Bit).

> Bei geraden Feldern ist das dann schneller als immer
> nur 1 Byte zu kopieren.

Das wäre die Hoffnung. Was der Prozessor unter der Haube aus den
String-Instruktionen macht, ist von Generation zu Generation
verschieden. Im Zweifelsfall: Messen!

> Aber bei nicht linearer Größe - ist da SB vorzuziehen ?

Du meinst bestimmt bei ungerader Größe (bzw. kein Vielfaches von der
"Word"-Größe). Die übliche Vorgehensweise ist, so viel wie möglich mit
der schnellsten Variante in großen "Happen" zu kopieren (bspw. 32 Bit)
und den Rest oder auch den Anfang in kleineren "Happen" (16 bis 8 Bit)
zu handhaben.

Aber hey, du kopierst wie viel? 32 Byte?! Da würde ich mir erstmal keine
Gedanken machen.

Gruß, Steffen