目次

ニュース

日記カテゴリ

書庫

メモリ番地

DSPのアセンブラのプログラミングをやっていると、どうも奇数番地にメモリが配置されていて気になります。
基本的にマイコンと違って、16bitまたは、32bit「しか」扱えないので、x86のように

 mov ah,2  # AXのHighレジスタに2を8ビットで代入
 mov ax,4c00h # AXレジスタに4C00を16ビットで代入

みたいな柔軟性はありません。そんなわけですから、すべてのメモリ番地に32bitのDWORDデータが存在しているわけですが…。
x86の16bitレジスタもレジスタを上下分割するだけで、実際のメモリ番地としては16bitごとに配置されるわけで奇数には置かれないはずなんですよね。

ところで、Javaのバイトコードなんていうのはどんなインタプリタなんでしょう？
バイトコードっていうからには、8ビットのインタプリタコードのような気がするけれど。

投稿日時 : 2007年10月15日 13:14
Feedback
  • # re: メモリ番地
    774RR
    Posted @ 2007/10/15 13:35
    16bitだろうが8bitだろうが64bitだろうが
    レジスタはメモリに置かれない、と思うのだが

    日本語でＯＫ、って言っていいっすか？
  • # re: メモリ番地
    ながせ
    Posted @ 2007/10/15 13:52
    そんなことは言ってません。

    ２バイト境界のメモリ空間か４バイト境界しかアクセスしないということです。
  • # re: メモリ番地
    774RR
    Posted @ 2007/10/15 16:23
    SH2なら俺もバリバリ使っております。回路も組めます。
    RISC-CPUのメモリアクセスがどういうものかは知ってるつもり。

    でも
    > 奇数番地にメモリが配置されていて
    > 実際のメモリ番地としては16bitごとに配置されるわけで
    って文書が何をどう主張しているのかさっぱりわからんとです。
    求む解説

    あーもしかして１バイト＝３２ビットと言いたいだけですか？
  • # re: メモリ番地
    凪瀬
    Posted @ 2007/10/15 16:42
    明確な記述があるかは記憶に無いけど、1byte=8bit系でしょうね。
    Javaのclassファイルを表すマジックナンバーが0xCAFEBABEというのは有名な話。
    1byte=7bit系とかではないのは暗黙の了解と思われ。

    どんなインタープリタって何の扱いを「どんな」って聞いてます？
    JavaのVMはスタックマシンになっていて、バイトコード上ではメモリアドレスは登場しないはずですよん。
  • # re: メモリ番地
    ながせ
    Posted @ 2007/10/15 17:23
    ＞774RRさん
    DSPは1バイト=32bitで命令長は1バイト、マイコンは1バイト=8bitで命令長は2バイトなので混乱しますよね。
    だけれどJavaのプログラムコードは1バイトのプログラムコードになるんだろうか？
    っていうだけです。お目汚しで大変失礼しました。

    ＞凪瀬さん
    ARM11っていうプロセッサがJazeleeというJavaを扱えるらしいので、バイトコードってそもそもCPUが直接実行できるのかなとふと思いまして。
    前述しましたけれど、JavaのVMって命令コードはバイトコードと呼ばれているので1バイトだとすると、8ビット長の命令なのでしょうか。
  • # re: メモリ番地
    凪瀬
    Posted @ 2007/10/15 17:44
    1Byte=8bit(要するにオクテット)でVMの命令長は1byteですね。
    http://java.sun.com/docs/books/jvms/second_edition/html/Mnemonics.doc.html

    昔、富士通がPicoJavaというバイトコードを直接実行するチップを開発したりしていましたが、その後あまり話を聞かないな…。

    リアルなハードとしてスタックマシンってのはちょっと知りませんが、
    ハード設計上の難しさとかあるのかな？
    wikipediaによるとコード密度が高いという特徴があるらしい。
    http://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%E3%83%9E%E3%82%B7%E3%83%B3
  • # re: メモリ番地
    ながせ
    Posted @ 2007/10/15 18:33
    Javaの思想だとリアルハードはちょっと難しそうですね。
    どのあたりがって言われるとガベージコレクションあたりかなぁとしか言えないのですが。
    Jazelleも命令コードの一部の実装のようですし。

    スタックマシンの件はちょっと面白そうなのでFPGAの例を見ながらちょっと追ってみます。

    ありがとございます。
  • # re: メモリ番地
    やまだ@風邪っぴき
    Posted @ 2007/10/15 21:34
    >1Byte=8bit(要するにオクテット)でVMの命令長は1byteですね。
    スタックマシンなのは凪瀬さんのおっしゃる通り、レジスタもメモリアドレスも明示的には登場しません。
    で、Java VMってのは命令こそ１バイトですが、命令によってはoperandがコンスタントプールって領域のインデックスを指してます。
    そのコンスタントプールってのはTLV形式の溜り場になってるわけで、そこから順次必要なデータを取得していく仕掛けになってます。
    ですので命令そのものはシンプルでも、コンスタントプールの処理はハード化困難だと思われます。
    ＃意味不明なこと書いてたら、風邪による熱のせいだということでorz
  • # re: メモリ番地
    ながせ
    Posted @ 2007/10/15 23:02
    ＞やまださん
    む、難しい…。

    固定的な長さのOperandをFetchするのとはまた違う世界のようですね。

    1バイトのFetchで命令系統どーなってんの？と思ったのですが、コンスタントプールといったところまではまったく考えておりませんでした。
  • # re: メモリ番地
    やまだ
    Posted @ 2007/10/16 10:10
    ぶっちゃけていうと、命令を簡単にするために、それ以外の要素を全部コンスタントプールってとこに突っ込んじゃった感じです。
    Tagのバリエーションが半端でなく多かった気がするので、GCとか外しても処理系をフルで実装するのは大変かも。
    逆にこの辺をばさばさ切ると、疑似VMの実装は結構簡単かと。私はZ80上で作ったことありますし(あ、ソフトで、ですけど)。

  • # re: メモリ番地
    やまだ
    Posted @ 2007/10/16 10:19
    あ、書き損ねました。
    >固定的な長さのOperandをFetchするのとはまた違う世界のようですね。
    Operandそのものは命令ごとに固定長だったはずです。ですが、そのOperandがコンスタントプールへのインデックスだったりするので、事実上は可変長のOperand といえるかもしれません。
  • # re: メモリ番地
    ながせ
    Posted @ 2007/10/16 17:27
    Z80でVMなんてすごいなぁ…。
    このコンスタントプールっていところがいわゆるデータセグメント対するインデックスが入っているていう感じですか。
    ちょっとクラス自体のファイルを調べてみたのですが、このコードって結構命令の集積度高いですね。

    …ってこれはC#というか.netにも言えることか。

    どうもありがとうございます。
  • # SGFaiiDjQv
    http://oemfinder.com
    Posted @ 2011/09/29 14:01
    YZNdqQ Left on my site a link to this post. I think many people will be interested in it..!
タイトル
名前
Url
コメント 

Blog 利用状況

コミュニティ

プロファイル

Powered by:

Copyright © ながせ