アカウント名:
パスワード:
8080 vs 8088
ソースはトランスレータが移植に使われたんでしたっけ。
CP/MもMS-DOSもカーネルのかなりの部分はファイルシステムだし、CP/MとMS-DOSとでファイルシステムの構造からして違うし、トランスレータなんか使うとこほとんどないと思うぞ。
当時はハードウェア直接アクセスがずっと当たり前に行われてたけどそれでもシステムコールを利用する限りにおいてはほとんど機械的な置き換えだけで移植できたんだよ。わざわざCP/Mと同じ方法(CALL 5H)でシステムコールが呼べるようにしてみたり
アプリの移植とOSの移植と区別つかない人ですか?
大元コメのトランスレータはアプリの話であって、お前がOSの話だと勘違いしてるだけやないの？
じゃあ大元コメは関係ない話をしてることになるなｗ
>ソースはトランスレータが移植に使われたんでしたっけ。の変換のソースはどこからやってくるんだよ。CP/MのソースをMSが持ってるわけじゃないんだから、アプリの話だと分かるだろ。
の変換のソースはどこからやってくるんだよ。
ふつーに考えて逆アセンブルだろ。
逆アセンブル→トランスレート→アセンブルするぐらいだったら、直接バイナリ変換すると思う。
完全に自動でできるわけではなかったから人間にも(多少は)読みやすい形式のほうが都合よかったんじゃね。当時は16進のダンプリストを直接読めたとかオープンリールの磁気の濃淡からプログラムを読み取れたとか信じられないような伝説もあるみたいだけど
コードとデータの判別どーすんの？
当時のコードは自己書き換えとか命令の途中にジャンプで飛び込むと違う命令列として解釈されるとか当たり前のように行ってたしな
CP/M-80でしたら、BDOS（ファイルシステム）とCCP（コンソール）はそんなトリッキーなことはしてなかったような。大半はPL/Mで書いてあって、レジスタの使い方が決まっていましたし。
思い出すと、ユーザプログラムのロードを低位アドレスからにしているため、CP/M自体は最上位に置かれました。ただしユーザが使用するメモリサイズを自由に（といっても上限64kB）設定できるので、OSのメモリマップが確定しません。ところが8080は絶対ジャンプ／コールしかできないのでプログラムはリロケータブルにできません。そこで、専用のリロケータがOSの一部として含まれていました（MOVCPM．COM）。これは逆アセンブルしてみたところ、たとえばDEレジスタにポインタが入っている、といった前提で絶対アドレスを書き換える仕組みのものでした。なので、あまりハンドコーディングで最適化してしまうと問題がでたんじゃないかと想像します。
BIOS（コンソールやFDDなどの入出力）はハードウェア依存なので、お手本のソースが添付されており、それをユーザがめいめいカスタマイズして使うことができました。もちろん、メーカーが自社製品に添付するものは専用にカスタマイズしたものが最初からFDに書き込まれれていましたが、多くはソースコードが添付されていたようです。
以上オフトピック気味な昔話でした。
マルウェア業界では今でも使われてませんか？＞命令の途中にジャンプで～
途中の命令にジャンプ～は使われてると思うけど、命令の途中にジャンプ～はあんまないんじゃないかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
ヒント (スコア:0)
8080 vs 8088
ソースはトランスレータが移植に使われたんでしたっけ。
Re: (スコア:0)
CP/MもMS-DOSもカーネルのかなりの部分はファイルシステムだし、CP/MとMS-DOSとでファイルシステムの構造からして違うし、トランスレータなんか使うとこほとんどないと思うぞ。
Re: (スコア:-1)
当時はハードウェア直接アクセスがずっと当たり前に行われてたけどそれでもシステムコールを利用する限りにおいてはほとんど機械的な置き換えだけで移植できたんだよ。わざわざCP/Mと同じ方法(CALL 5H)でシステムコールが呼べるようにしてみたり
Re: (スコア:0)
アプリの移植とOSの移植と区別つかない人ですか?
Re: (スコア:0)
大元コメのトランスレータはアプリの話であって、お前がOSの話だと勘違いしてるだけやないの？
Re: (スコア:0)
じゃあ大元コメは関係ない話をしてることになるなｗ
Re: (スコア:0)
>ソースはトランスレータが移植に使われたんでしたっけ。
の変換のソースはどこからやってくるんだよ。
CP/MのソースをMSが持ってるわけじゃないんだから、アプリの話だと分かるだろ。
Re:ヒント (スコア:0)
ふつーに考えて逆アセンブルだろ。
Re: (スコア:0)
逆アセンブル→トランスレート→アセンブルするぐらいだったら、直接バイナリ変換すると思う。
Re: (スコア:0)
完全に自動でできるわけではなかったから人間にも(多少は)読みやすい形式のほうが都合よかったんじゃね。当時は16進のダンプリストを直接読めたとかオープンリールの磁気の濃淡からプログラムを読み取れたとか信じられないような伝説もあるみたいだけど
Re: (スコア:0)
コードとデータの判別どーすんの？
Re: (スコア:0)
当時のコードは自己書き換えとか命令の途中にジャンプで飛び込むと違う命令列として解釈されるとか当たり前のように行ってたしな
Re:ヒント (スコア:4, 興味深い)
CP/M-80でしたら、BDOS（ファイルシステム）とCCP（コンソール）はそんなトリッキーなことはしてなかった
ような。大半はPL/Mで書いてあって、レジスタの使い方が決まっていましたし。
思い出すと、ユーザプログラムのロードを低位アドレスからにしているため、CP/M自体は最上位に置かれました。
ただしユーザが使用するメモリサイズを自由に（といっても上限64kB）設定できるので、OSのメモリマップが確定しません。
ところが8080は絶対ジャンプ／コールしかできないのでプログラムはリロケータブルにできません。
そこで、専用のリロケータがOSの一部として含まれていました（MOVCPM．COM）。
これは逆アセンブルしてみたところ、たとえばDEレジスタにポインタが入っている、といった前提で絶対アドレスを
書き換える仕組みのものでした。なので、あまりハンドコーディングで最適化してしまうと問題がでたんじゃないかと
想像します。
BIOS（コンソールやFDDなどの入出力）はハードウェア依存なので、お手本のソースが添付されており、それをユーザが
めいめいカスタマイズして使うことができました。もちろん、メーカーが自社製品に添付するものは専用にカスタマイズ
したものが最初からFDに書き込まれれていましたが、多くはソースコードが添付されていたようです。
以上オフトピック気味な昔話でした。
Re:ヒント (スコア:1)
マルウェア業界では今でも使われてませんか？＞命令の途中にジャンプで～
Re: (スコア:0)
途中の命令にジャンプ～は使われてると思うけど、命令の途中にジャンプ～はあんまないんじゃないかな。