INT15によるメモリ情報取得に関して アセンブリ言語

Question

INT 15によるメモリ情報取得をやっているのですがそれについて分からない点があるのでお願いします。

リンク内容

mov eax,[di + 16]

の部分がよくわかりません。
INT 15 eax = E820H　を行うことによりメモリマップの情報をES:DIで表すアドレスの場所に
保存する・・・ということをやっているはずです。
Int 15/AX=E820h　返り値

まず、diレジスタには何が入っているのか？

mov di,.b0

という命令がありました。.b0はラベルなのでどこかに定義されているだろうと探したのですが
定義されていませんでした。（見落としているだけ？）

とりあえず、格納するアドレスの下位がdiに入っている。（リアルモードで実行する　だから上位のESは16bit余計なので使わない　たぶん）

で、そこのアドレスには下記の情報が格納されるそうです。
リンク内容

00h	base address　（低位ビット）
08h	レングス(byte)
10h	メモリマップタイプ　（高位ビット）

よって、よってDIが示すアドレスには・・・
(リトルエンディアンだから高位ビットが下位アドレスに入る。)

---DI---(アドレス下位)
           メモリマップタイプ 6bit
　　　　	レングス(byte) 2bit
　　　　	base address 8bit
        (アドレス高位)
```

なので、di + 16としてしまうと
まったく別のところを指してしまう気がするのですが・・・

どっから認識が曲がっているのでしょうか？

分からないのでお願いします。

Comments

[dodox86]

> mov ax,[di + 16] の部分がよくわかりません。
質問と回答に影響がある訳ではありませんが、
mov eax, [di + 16] です。（転記ミス）

[kazuyakazuya]

すみません
あとで訂正しておきます

[tacsheaven]

ちなみに ES などのセグメントレジスタは、（例え x64 な CPU でも）16bit しかありません。
80386 以降のプロテクトモードでもセグメントレジスタは「セグメントディスクリプタテーブルのインデックス」を示しているので、16bit で十分であるため拡張していないのです。（セグメントレジスタ自体の数が足りないので増やしてはいますが）

[kazuyakazuya]

ありがとうございます。
32bitCPUだけならず64bitでも
セグメントレジスタは16bitなんですね。

Answer 1

10h メモリマップタイプ　（高位ビット）

10hは１０新表記では、１６でしょう。
ということで、

mov ax,[di + 16]

というのは、type of address rangeの低位側をaxに、ですな

---

00h QWORD base address

08h QWORD length in bytes
10h DWORD type of address range (see #00581)

オフセット０からの８バイト（QWORD）はbase address
オフセット８からの８バイト（QWORD）はlength in bytes
オフセット１６からの４バイト（DWORD）はtype of address range

Comments

[kazuyakazuya]

すみません。
誤解がありました。渡されるバッファは16bit
ではなく20bitですね

00h base address 8
08h レングス(byte)8
10h メモリマップタイプ 4

ビッグエンディアンなら確かにこうなりますが
x86系はリトルなので
下のように反対になってしまうと思うのですが。。。

(アドレス下位)
メモリマップタイプ 4bit
　　　　 レングス(byte) 8bit
　　　　 base address 8bit
(アドレス高位)

[y_waiwai]

ビット、ではなく、バイトですぜ

[y_waiwai]

メモリ配置
<base address+0> ← [di+0]
<base address+1>
<base address+2>
<base address+3>
<base address+4>
<base address+5>
<base address+6>
<base address+7>
<length in bytes+0> ← [di+8]
<length in bytes+1>
<length in bytes+2>
<length in bytes+3>
<length in bytes+4>
<length in bytes+5>
<length in bytes+6>
<length in bytes+7>
<type of address range+0> ← [di+16]
<type of address range+1>
<type of address range+2>
<type of address range+3>

[kazuyakazuya]

すみません バイトでした。

ビッグエンディアンなら
<base address+0> ← [di+0]
<base address+1>
<base address+2>
<base address+3>
<base address+4>
<base address+5>
<base address+6>
<base address+7>
<length in bytes+0> ← [di+8]
<length in bytes+1>
<length in bytes+2>
<length in bytes+3>
<length in bytes+4>
<length in bytes+5>
<length in bytes+6>
<length in bytes+7>
<type of address range+0> ← [di+16]
<type of address range+1>
<type of address range+2>
<type of address range+3>
こうなるかもしれませんが
リトルエンディアンはこの逆になってしまうと思うのですが。。。

これってビッグエンディアンを前提としたプログラムなのでしょうか？

[y_waiwai]

うーん、根本的になんか勘違いしてますね。エンディアンはどういうことかを調べてみよう

ビッグだろーがリトルだろーが
---
オフセット０からの８バイト（QWORD）はbase address
オフセット８からの８バイト（QWORD）はlength in bytes
オフセット１６からの４バイト（DWORD）はtype of address range
---
の並びは変わりません

[kazuyakazuya]

これらのデータがメモリに配置されるさいに
エンディアンにより
順番が変わってくるという認識だったのですが
そこから違いますか？

[y_waiwai]

そこから違います
base addressの８バイトを並べるのに順番が変わるだけ、です
＃length in bytesとtype of address range もおなじ

[kazuyakazuya]

なんだか根本から認識が間違っていますね・・・。

ー低位バイトー

base address ０
base address １
base address ２
・・・
ー高位バイトー

みたいに存在していたら、リトルエンディアンで
<base address　７> ← [di+0]
<base address　６>
<base address　５>
<base address　４>
という感じでしょうか？

[y_waiwai]

0x12233445
という32ビット数値をメモリに格納するとき
<0x45>
<0x34>
<0x23>
<0x12>
と格納されるのがリトル

<0x12>
<0x23>
<0x34>
<0x45>
と格納されるのがビッグエンディアン

[kazuyakazuya]

baseaddressの
低位ビットがある方のバイトから
配置されていくんですね。

[kazuyakazuya]

01h memory, available to OS
02h reserved, not available (system ROM, memory-mapped等)
03h ACPI Reclaim Memory
04h ACPI NVS Memory
は１バイトだから順序は不変

baseaddress とレングスは複数のバイトで構成されているので
ビッグとリトルで順序が変わってくる。

そこは分かったのですが、base_addressのデータそのものは
データ領域・スタック領域のどちらかに置くかで
データ領域なら下位アドレス→上位アドレスに積まれていくから
-下位-
base_address
レングス
memory, available to OS
reserved, not available
ACPI Reclaim Memory
ACPI NVS Memory
-上位-

リトルかビッグかはbase_address　レングスなど複数バイトで構成されているデータの
バイトの積まれ方が変わってくる。

スタックは上位→下位なので
データと反対に積まれていく
ー低位ー
レングス
base_address
ー上位ー

という感じですか？

[y_waiwai]

エンディアンってのはCPUの都合によるものなんで考えんでよろしい。
間違ってる上に難しく考えすぎ。

エンディアンは考えなくてよろしい

[kazuyakazuya]

エンディアンと言われると

mov ax,0x0A0B

このaxに入れられるバイト順が変わってくる
見たいのをイメージしていましたが
もうそこから違いましたか？
今までこれを前提に考えていたのですが。。。

[y_waiwai]

ちがいますｗ
バイト単位のメモリに格納／読み出すときにどういう順番なのかってだけのはなし。
処理に影響するもんではないです

[kazuyakazuya]

今回もとんでもない勘違いを引き起こしていました。
調べなおします・・・。

[kazuyakazuya]

いつも通り、根っこから勘違いしていて理解が進まないのだと思うのですが・・・

上位バイトのデータから下位アドレスへ格納するのがビッグエンディアン
下位バイトのデータから上位アドレスへ格納するのがリトルエンディアン

そのメモリっていうのはデータ領域だろうがスタック領域だろうが
同じことが言えるのですか？

[y_waiwai]

そういう区別はありません。
区別する理由もないし

まえからいってることですが、実機を前にしてやってみましょうよ。
机上で、アタマの中でどーこーやってても何も進みませんぜ

[kazuyakazuya]

たぶん　理解できました。
少なくてもx86なら最初の構造体要素から取り出されて積まれていく。
高位からか低位からかは
データ・コード　スタックで違う。
エンディアンはその要素を構成しているバイトの入れ方の問題。

そもそもなのですがINT 15 E820によって手に入れられる
マップ情報とは一体なんですか？

base address・・・手に入れた情報の対象メモリのベースアドレス
レングス(byte)・・・その対象メモリの範囲
メモリマップタイプ・・・？

このメモリマップタイプは以下のような構造になっているみたいですが
01h memory, available to OS
02h reserved, not available (system ROM, memory-mapped等)
03h ACPI Reclaim Memory
04h ACPI NVS Memory
結局、INT 15 E820をすることで何が分かるのでしょうか？

[y_waiwai]

その参考サイトを読みましょう。
メモリマップがでてくると書いてあるんだからそういうことなんでしょう

そもそも古いBIOSの動作なんですから、イマサラ詳細がわかったところで使いみちもないし、実行できる環境もないということでいいんじゃないでしょうか。

[kazuyakazuya]

そうですね。ずっとこれにこだわって前に進まないのはよろしくないので
一旦飛ばしちゃいます。（笑）
ただ、ACPIってシャットダウンの処理に必要なんじゃ。。。