アセンブラ 13
■ このスレッドは過去ログ倉庫に格納されています
ちょっとお尋ねします 手続きカウンタの値により手続き順に処理を飛ばすプログラムを考えています この時手続きカウンタの評価が先頭につきますが このオーバーヘッドがいやなのでProgramCounterに次の処理の飛び先をロードしてjumpさせたいのですが if 手続きカウンタ==1 jump 処理1: if 手続きカウンタ==2 jump 処理2: : if 手続きカウンタ==n jump 処理n: 手続きnが多いとオーバーヘッドが無視できなくなる else 出口: 処理1: { : jump_出口: 手続きカウンタ +=1 } // ここをPCに代入するための飛び先番地に変更 処理n: { : 手続きカウンタ=1(手続きカウンタ初期化) // ここをPCに代入するための処理1の飛び先番地に変更 jump_出口: } 出口: 通常のCPUのJUMP命令は直値のみでレジスタ間接は無いので変化球技で実現する必要があります こんな変なことをやって居る方はおられますか? 又、どのように実現したのでしょうか? x86とかならjump [mem] やjump reg があるよ 場合によっては、スタックに戻り先とジャンプ先を積んでretしてもいい いや普通のCPUにはレジスタ間接ジャンプあるよね? わいの今使ってるCPUのニーモニックを目を皿のようにして探しているんだが レジスタ間接ジャンプがないんやでえええ 見方が悪いのかもな 普通そんなことありえないか・・・そうだよな? テーブルジャンプなんて普通に使うもんな Cコンパイラがあるならswitchでコード書いてアセンブラソース吐かせろ 多分テーブルジャンプになるんじゃないかな Cコンパイラが使える環境なのか? なら素直にCで書けば 本当にジャンプ位置をダイナミックに決められないのなら、 2分検索とかでいいし、率がわかっているならもうちょっと頭の良い方法でも良い 1個ずつ分岐するのは大抵の場合効率が悪い ID:DMOHal5+はハマってるのかな? MCS51じゃあないよな avrってメモリ保護とかあるの? なければ ・jmp命令とオペランド(飛び先)をテーブルにする ・機能番号でテーブルからjmp命令を拾ってくる ・次のjmp命令を書き換える だけじゃねぇか そこだけram上でやればいい 多分岐switchのアセンブラ出力をパクるのが一番か 関数ポインタが確実だろ。switchはifでも実装できる。 あー関数テーブルか失礼 C使えるんだからソレでいいと思うけどね AVRなら、IJMPというそのまんまな名前の間接ジャンプ命令があるようだ。 ┌○┐ │死|ハ,,ハ │ |゚ω゚ ) │刑| // └○┘ (⌒) し⌒ ┌○┐ │ハ|ハ,,ハ │ |゚ω゚ ) │ゲ| // └○┘ (⌒) し⌒ 1164ページw でも、PowerPCとか需要あるのか? アセンブラ自体だけじゃ無くて、考え方を考える本でもあるからな。 ★☆☆☆☆w virtex-6以降はpowerpcコア搭載タイプ無いのかすぃら? Z80の本が出たときは我慢出来たけど 6800の本が出たときは逝ってしまった zeas88 一月かけて入力して動かなかった 三月かけてダンプをチェックしても動かなかった 思い出した 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 VM3VN Intel記法とAT&T記法ってどっちがいいと思う? 思う? とか訊いておいて 実は俺のなかではAT&T記法のほうがいいと思ってるw 例えば add eax,4 addl $4,%eax という命令があってAT&T記法のほうはUnixで用いられているコマンド (というかOS/2系列でも同じようなコマンドがあるが) $ copy aaa.txt bbb.txt の文法に並びがそっくりだし,変数に$を前置するというのもUnixで最もよく用いられているB系シェルの 変数を表わす規則と同じ。レジスタに%が付いてるのも分かりやすいと思う。 今主流なのはIntel記法なので 残念ながら俺は少数派なんだろうがw >>395 チェックサムは、 ・・・ A B ・・・SUM1 ・・・ B A ・・・SUM2 見たいな間違いがあると、縦横チェックサムであっても、 間違いに気づく事が出来なかったなぁぁ・・・。 雑誌に書いてあったバイナリコード : ・・・ A B ・・・SUM1 ・・・ B A ・・・SUM2 間違って入力したコード ・・・ B A ・・・SUM1 ・・・ A B ・・・SUM2 これだと、横・縦の両方のチェックサムが雑誌と同じになってしまう。 >>396 gccでIntel記法でアセンブラ出力できるよ gcc -S -masm=intel hogehoge.c インラインアセンブラでIntel記法使う場合も gcc -masm=intel hogehoge.c objdumpでIntel記法で逆アセンブルする場合は objdump -M intel -d hogehoge.obj 396ですが,AT&T記法を中心に学ぶことにしました。 理由は,2つあり, ・OSの勉強をするためにこれから読んでいこう(というか既に読んでいる) UNIX v6 for x86のアセンブラがAT&T記法である ・仕事でアセンブラを使う訳ではないので,今現在普及しているものでなくてよい つまりIntelが発表するCPUの最新機能を使ったりする機会がないので 枯れた情報しかないAT&T記法でも十分やっていけると考えた ということです。 まあ,チラ裏ですが,これから個人でアセンブラを学ぶとしてる人が見てれば参考にして下さい。 Intel・AT&T 記法を抽象化した、仮想アセンブラのLLVM で学べ! 情報処理資格でも、仮想アセンブラのCASL 2 gdbの逆アセンブラも set disassembly-flavor intel と打ち込めばIntel記法で逆アセンブルしてくれる デフォルトでIntel記法にしたいならホームディレクトリの.gdbinitに上記を記述 詳しくはググると出てくるかも ARMは mov r0, #4 64bitのARMは mov x0, #4 と右から左 MIPSも li $4, 4 RISC-Vも li a0, 4 と右から左 PowerPCも li %r3, 4 と右から左 今のパソコンやサーバでメジャーなCPUの多くが右から左 しかしどうして右から左に読むのでしょうね。 英語だと特に move number to address と自然に読み下せるのに。(というかニーモックってまさにその目的の筈では……) 左右なんてどっちでもいい 記法もどっちでもいい もっと本質的なことに頭使え アセンブラの本質って機械語不便だからわかりやすくする記法なのに それに気を使わずにどこに頭使うの? >>407 ある種の文化の衝突が起きていると思う。 事実標準に近かったZ80などでは、語順的には、今「Intel記法」と 呼ばれているものだった。でもIntel記法よりも洗練されている 感じだった。それが、人気があったひとつの理由だと思ってる。 でも、学者などは、さかさまに固執するような印象が多い気がする。 なんでも市場や事実標準とは逆を好む天邪鬼みたいな姿勢の人が多い。 たとえば、NEC機が流行っていたころは、京大構内では日立マシンが標準だった。 今、Windowsマシンが標準なのに、灯台ではMacが標準。 >>411 学者は、事実標準に逆らったことをするのが大好き。なぜなら、そうすれば、 自分たちが優位になると思っているから。 たとえば、数式処理プログラムのMaximaも、LISPで書かれているし、 AI関連のライブラリが充実している言われる、Pythonも然り。 東大がMacを標準にしたのは、表向きはMSの独占的地位を破壊するため かも知れないが、裏には、プログラミングが得意な学生に学者が負ける と面目を保てなくなるのが困るからではないかと考えられている。 >>408 それは a is b とか読むんじゃないですかね。 UNIX v6やv7が使われた16bitミニコンのPDP-11やBSDが使われたVAX11が左から右の記法だった PDP-11からの影響を受けた680x0も左から右 だから1970年代、1980年代前半から半ばまでのUNIX界隈では左から右が主流だった だからx86のAT&T記法が左から右なんだろうな 1980年代終り頃に普及したMIPS、POWERが右から左の記法 (よく知らないがSPARCやPA-RISCは左から右のようだ) 要するに左から右の記法はPDP-11の影響を受けてるわけだ (VAX11はPDP-11の後継の32bitミニコン) SPARC、PA-RISCが左から右なのは 680x0を使ったワークステーションの後継機種用のCPUとして作られたからだろうな 今でも680x0の影響を受けてるCPUは左から右 逆に言えば、パソコンやサーバ、スマホなどは PDP-11、VAX11、680x0などのCPUの影響を受けてないCPUが主流 そういう経緯とか全然知らんかったわ。 Z80は古い機種だと思うんだけど,>>411 によればIntel記法に近いらしい。 一概に,「昔はAT&T記法が主流だった」とも言えねえのな。 >>416 Intel 8080 の改良版が、Z80。 以下、同じ命令を、8080とZ80について書いてみる。 Z80の方が現代のアセンブリ言語に近く、人間には覚え易くて 理解しやすいが、アセンブラの作成が当時としては難しくなった。 Z80がなぜ人気が爆発したか、これだけ見ても分かるかと思う。 【8080】 MVI A,byte ; A <-- byte // move immediate を略して MVI MOV A,B ; A <-- B // 意味は同じなのに、第二オペランド // がレジスタに変わったなっただけで命令表記が変わる。 MOV A,M ; A <--(HL) // M の意味は、(HL) MOV H,A ; H <-- A MOV L,A ; L <-- A LXI H,word ; HL <-- word // これも意味は move なのに命令が変わる。 LHLD word ; HL <---(word) // これも、現代なら単に(word)と書けばいいとこ // ろが命令自体を変えなければならなかった。 【Z80】 LD A,byte LD A,B LD A,(HL) LD H,A LD L,A LD HL,word LD HL,(word) 【参考】 http://nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.html >>415 命令表記を左右逆にしていれば、今頃 68000 が天下を取っていたかもしれない。 高級言語の「A = B」がそのまま、MOV A,B と書けるのはやはり分かりやすいので。 >>417 昔も今もそうかもしれないが、IntelもMSも、余り「判りやすく書く」 「すっきりと設計する」ということが余り得意ではないかもしれない。 MSの作ったAPIは構造が汚い。 Zilogがせっかく、二モニックを美しく修正したのに、Intelは、また、MMX や SSE以後で 汚くしてしまった。 それに、セグメントの概念もMMUの設計もひどかった。 セグメントに関しては、トランジスタの集積度が少なすぎてしょうがなかったのかも しれないが、それを長く引きずりすぎた。 80386のプロテクトモードなんかどうでも良くて、単にプロテクトの無い32BITの フラットモードがあれば喜ばれ、MS-DOSが今でも続いていたかもしれない。 >>418 しつこくてすまんが $ cp file.org file.new $ mv file.org file.new ↑こういう操作を考えると AT&T記法のほうが馴染みやすくない? >>421 個人的には、数学や物理の表記の方が親しみがある。 >>423 http://afsoft.jp/os/p02.html CP/M も copy コマンドは、「左から右」だったと思うけど: COPYコマンド ディスクをコピーします。 【書式】COPY {mode} {コピー元} {コピー先} mode : ALL・・・ディスク全部をコピー BOOT ・・ブートトラックをコピー FILES・・ブートトラック以外をコピー コピーではないが、rename コマンドにそれらしき痕跡はあった。 確かに、右から左で、しかも、「=」記号もつけていたらしいね: http://www.discordia.org.uk/px4/cpm.html REN [d:]newname.ext = oldname.ext Change the name of a disk file from oldname.ext to newname.ext これかな??? PIP [d:][newfile.ext]=[d:][filespec][<t> Copy files between peripherals whilst performing optional conversion <t>. Copy file from drive to drive: C> PIP H:=A:INFO.DAT Copy file to new name: C> PIP A:NEW.DAT=A:INFO.DAT Copy file to printer: C> PIP LST:=A:LETTER.TXT 確かに有った。copy コマンドが登場するより前に、PIP コマンドがあったのか。 知らなかった。 https://en.wikipedia.org/wiki/Peripheral_Interchange_Program The original PIP syntax was PIP destination←source /switches using the left-arrow character from the ASCII-1963 character set that the Flexowriter keyboards of the time used. As other terminals were introduced that used later versions of ASCII (without the left-arrow character), PIP allowed the syntax PIP destination=source でもcopyコマンド(in CP/M)自体はUnix風の動作なんだよね。 pipコマンドというとPythonのアレしか思い浮かばないがw pipはビルトインじゃなくて外部コマンドだったから数バイトのコピーするときにでも pipを読み込むために数十KBの実行ファイルをフロッピーゴトゴト言わせてからコピーが始まる >>435 マジかよww なんでそんな不便な方法しかなかったんだろう 当時はそれが一番効率的と考えられてたんかな MS-DOSのVer2.xxからはいろんな意味でUNIXをリスペクトしてるからな UNIX流にファイルハンドルでファイルを扱ったり、階層ディレクトリを導入したり、 環境変数を導入したりな マイクロソフト自身がXENIXというUNIXを販売してたしね マカーが散々捏造したきたようにその手の話は眉唾もの。 最近のC++コンパイラはAVX2命令ガンガン吐いてくるからすごいな あんま詳しくないが同じような処理を繰り返す場合には速いらしいな >>451 MMX, SSE〜SSE4, AVX, AVX2, AVX512 は、SIMD命令だから、ループを展開して、 ベクトル計算のように考え直した場合、そのベクトルの足し算やベクトルの 要素ごとの掛け算などが速くできるようになる。 C++で吐く場合ってあえてそうなるようにコーディングしてるんだと思うが ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる