| 掲示板の過去ログ（本文 2000/10/13-） | 2007-07-18(Wed) 21:18 |
|---|
X68の未公開機能ですが、一時期ハマっていた
SX-WINDOWの.CGAファイルに関する情報なら有ります。
IVMを隅々まで調べて作った資料だったりします。
私のページに有りますので、適当にリンクしてやって下さい。
P.S.
FSX.xの未公開コールとかも知ってるけど、
資料としてはまとめてないです(^^;
M.Suzukiさん、こんにちは。
> X68の未公開機能ですが、一時期ハマっていた
> SX-WINDOWの.CGAファイルに関する情報なら有ります。
> IVMを隅々まで調べて作った資料だったりします。
> 私のページに有りますので、適当にリンクしてやって下さい。
ありがとうございます。
SX-WINDOW関係の資料は解析結果にもとづいているものが
多いですね。
> P.S.
> FSX.xの未公開コールとかも知ってるけど、
> 資料としてはまとめてないです(^^;
FSX.Xを完全に解析した人って、何人くらいいるのかな。
私は、KeyWitchをやっていた頃に、キー入力回り
（SXCON.Xを含む）を見たくらいです。
A-line処理を高速化しようとして68000の変な挙動を発見
した頃から、興味の対象がFSX.Xから逸れていきました。
鎌田さん、こんにちは。
日記を読んでいてフと思い出しましたが、たしかOPT2押しながら
起動すると何か良い事（？）があったような。僕でも知っている
ので未公開じゃないと思いますが…。
記憶がほとんどないですが、確かROMデバ(?)だったかなんだった
か…X68が２台あると幸せ(?)になれるとかなれないとか。
何だったかなぁ…。
春麗さん、こんにちは。
> 日記を読んでいてフと思い出しましたが、たしかOPT2押しながら
> 起動すると何か良い事（？）があったような。僕でも知っている
> ので未公開じゃないと思いますが…。
> 記憶がほとんどないですが、確かROMデバ(?)だったかなんだった
> か…X68が２台あると幸せ(?)になれるとかなれないとか。
>
> 何だったかなぁ…。
ROMデバッガですね。
ROMデバッガは存在そのものが未公開だと思います。
ROMデバッガは起動方法が3通り（手動も含めると4通り）
あります。
こんにちは。
> ROMデバッガですね。
> ROMデバッガは存在そのものが未公開だと思います。
あぁ、やっぱりＲＯＭデバでしたね。家に帰ってから調べてみま
した。いや、なんか妙〜に気になってたもので（笑）。【プログ
ラマーのためのＸ６８０００環境ハンドブック】に載ってました。
いやはや、これでグッスリ眠れます。
学生の頃はアセンブラしかできなかったので、よく参照していま
した。手垢にまみれた本をみて、「あの頃はパワーあったなぁ」
なんて、ちょっと感慨深いものを感じました。今じゃ、Ｃ言語
にどっぷり頭まで浸かっています。ははは…
春麗さん、こんにちは。
> 学生の頃はアセンブラしかできなかったので、よく参照していま
> した。手垢にまみれた本をみて、「あの頃はパワーあったなぁ」
> なんて、ちょっと感慨深いものを感じました。今じゃ、Ｃ言語
> にどっぷり頭まで浸かっています。ははは…
同じようにCを理解しているつもりでも、アセンブラの
経験があるかどうかでCの理解度は大きく差がつきます。
Cを使うとき、「アセンブラの経験がない人には負けない」
という自信を持ちましょう。
たとえCの海にどっぷり浸かっていても、アセンブラは
いつもその足元、海の底のほうに広がっているものです。
その海に潜れる深さがCへの理解の深さです。
ときどき底まで潜ってみてはいかが？
海底散歩も楽しいかも知れません。
こんにちは。
> 同じようにCを理解しているつもりでも、アセンブラの
> 経験があるかどうかでCの理解度は大きく差がつきます。
先日の日記にもありましたが（関数のポインタへの配列の
定義うんぬん）、初心者の頃はポインタの代入や計算で、
よくワーニングを出して、その度に、
「move.l d0,a0でいいやん、move.l d0,a0で！」
「キャストめんどくせー！」
とかいろいろ唸ってました（笑）。
> ときどき底まで潜ってみてはいかが？
> 海底散歩も楽しいかも知れません。
制作中の2D格ゲーでは、スプライトダブラ（358個だからダ
ブラじゃないか…）などの肝心な部分は海底を歩いてます。
でも、ヘボなので、ノーマルX68での動作保証は諦めました。
※ 060turbo使ってると、速度感覚がマヒします（苦笑）。
春麗さん、こんにちは。
> 先日の日記にもありましたが（関数のポインタへの配列の
> 定義うんぬん）、初心者の頃はポインタの代入や計算で、
> よくワーニングを出して、その度に、
>
> 「move.l d0,a0でいいやん、move.l d0,a0で！」
> 「キャストめんどくせー！」
>
> とかいろいろ唸ってました（笑）。
あるある。
それでキャストをつけまくる癖がついてしまい、今度は
他の人に「お前、キャスト多すぎ」なんて批判されたり。
-WallでWarningが出ないようにすることに燃えてしまい、
ふと気付くと効率の悪いプログラムになっていたり。
「関数へのポインタの配列の定義」は、Warningどころか
Errorになってしまう人が結構いるのではないかと。
> 制作中の2D格ゲーでは、スプライトダブラ（358個だからダ
> ブラじゃないか…）などの肝心な部分は海底を歩いてます。
スプライトダブラもハードの限界を超える発想ですよね。
水平32個の限界があるので、スプライトの数を増やす
だけでなく、どのように並べるかも工夫が必要ですね。
> でも、ヘボなので、ノーマルX68での動作保証は諦めました。
> ※ 060turbo使ってると、速度感覚がマヒします（苦笑）。
10MHzの68000と50MHzの68060ではワーストケースで100倍
以上の速度差がありますから、68000で動かすものを68060
で作ると、動作速度の違いに愕然とすることがありますね。
68060でI/Oの書き込みウェイトを活用して最適化した
プログラムは、68030でさえ這うように遅くなります。
こんにちは。
> -WallでWarningが出ないようにすることに燃えてしまい、
> ふと気付くと効率の悪いプログラムになっていたり。
エッ、そうなんですか。僕は、Wallつけてコンパイルしてい
ますが、特に速度的に効率が悪いとは感じた事はないです。
重要なループ以外は、最適化を気にせず組んでます。
> 「関数へのポインタの配列の定義」は、Warningどころか
> Errorになってしまう人が結構いるのではないかと。
僕も一発コンパイルは自信がないです（プログラマなのに）。
void (*proc[])( void *arg ) = { foo1, foo2, foo3....};
こ、こんな感じでしょうか。何も見てないので自信ないです。
> スプライトダブラもハードの限界を超える発想ですよね。
> 水平32個の限界があるので、スプライトの数を増やす
> だけでなく、どのように並べるかも工夫が必要ですね。
済みません、358個じゃなくて384個の間違いでした。ダブラ
エンジンを開発した当時は既にXSPがあったのですが、XSPは
一切参考にしませんでした（下らないプライドですが）。
で、後から、ドキュメントを見てみると、管理方法や高速化、
問題点などほぼ同じでした。やはり考える事は同じなんだなぁ
と思いました（ベースとなる原理が同じなので当然ですが）。
でも、僕のダブラの完成度はXSPの足元にも及びません（苦笑)。
春麗さん、こんにちは。
> エッ、そうなんですか。僕は、Wallつけてコンパイルしてい
> ますが、特に速度的に効率が悪いとは感じた事はないです。
> 重要なループ以外は、最適化を気にせず組んでます。
コードの効率というよりもデータ構造の効率を考えたとき、
Cの文法の範囲で表せないデータ構造を使いたくなることって
ありません？
アセンブラで書くようなデータ構造をCで模倣しようとして
unionやビットフィールドを使って無理矢理書いたものの、
Warningをなくすことができず、結局無駄の多いデータ構造に
変更してしまったりして、「ああ、ぬるい、ぬるすぎる…」
なんて嘆いたり。
他にCで効率が悪くなることと言えば、「ローテート命令を
使いたいとき」とか。
> 僕も一発コンパイルは自信がないです（プログラマなのに）。
> void (*proc[])( void *arg ) = { foo1, foo2, foo3....};
> こ、こんな感じでしょうか。何も見てないので自信ないです。
お見事。
この場合、関数へのポインタの配列の参照は
proc[n](＆arg);
ですが、定義のときだけ必要になる括弧を間違えやすい
と思います。
> 済みません、358個じゃなくて384個の間違いでした。
あ、やっぱり。中途半端な数だなぁとは思いました。（笑）
> ダブラエンジンを開発した当時は既にXSPがあったのですが、
> XSPは一切参考にしませんでした（下らないプライドですが）。
> で、後から、ドキュメントを見てみると、管理方法や高速化、
> 問題点などほぼ同じでした。やはり考える事は同じなんだなぁ
> と思いました（ベースとなる原理が同じなので当然ですが）。
> でも、僕のダブラの完成度はXSPの足元にも及びません（苦笑)。
XSPは汎用性を持った完成度の高いものですよね。
でも、384出せればたいしたものだと思います。
X68000版の「キャメルトライ」は偉大でした。
それを再現できるエミュレータも凄いと思います。
鎌田さん、春麗さん、こんにちは。
アセンブラの腕前は錆ついたままだが、Ｃは大丈夫だろう
と思っていたのですが、それも怪しくなってきました。
関数へのポインタの配列は、けっきょく、Ｚしーモンキー
を見て確認しました（苦笑）。うーん、あの頃はパワーが
あったなあ。最近、Perl を使うことが多かったので、
すっかり堕落したようです（笑）。リハビリしないとダメ
ですね。
それではまた。
広井さん、こんにちは。
> アセンブラの腕前は錆ついたままだが、Ｃは大丈夫だろう
> と思っていたのですが、それも怪しくなってきました。
普段使っていないと忘れてしまいますよね。
「関数へのポインタの配列」は機能番号からサブ
ルーチンを選択する場合などに使いますが、あまり
使用頻度は高くないかも知れません。
> 最近、Perl を使うことが多かったので、
> すっかり堕落したようです（笑）。
Perlは強烈な省略言語ですからねぇ。
あればっかりじゃ…。
広井さん、鎌田さん、こんにちは。
> > アセンブラの腕前は錆ついたままだが、Ｃは大丈夫だろう
> > と思っていたのですが、それも怪しくなってきました。
>
> 普段使っていないと忘れてしまいますよね。
僕は、BASICはもうスッカリ忘却の彼方です。OKの
あとに”.”ピリオドがついてたらコンティニュー
可能とかツマンナイ事しか覚えてません（笑）。
でも、アセンブラって月日が経っても命令表さえあ
れば何とかなりますよね（自転車と同じで）。それ
に何か一つでも（極めずとも）それなりに習得して
おけば、違うCPUでも何とかなりますよね。
僕はZ80と68kしかやっていなくても、8086の仕事は
できたし（セグメントはイヤでしたが）、VUの最適
化も楽しめました。
> 「関数へのポインタの配列」は機能番号からサブ
> ルーチンを選択する場合などに使いますが、あまり
> 使用頻度は高くないかも知れません。
数が少なければswitchでササッと書けるし、その
方が追加や変更など都合の良い場合もありますから。
特に、見た目に分かり易いですし（スパゲッティは
論外ですが)。
個人主観ですが、見た目は重要だと思っています
（速度重視の場合は仕方ないですが）。
春麗さん、こんにちは。
> それに何か一つでも（極めずとも）それなりに習得
> しておけば、違うCPUでも何とかなりますよね。
そうですね。どの CPU にしても原理的には同じ（フォン
・ノイマン・アーキテクチャ）なので、ひとつの CPU で
マシン語プログラムが組める人は、ほかの CPU でも何とか
なるでしょう。
> 僕はZ80と68kしかやっていなくても、8086の仕事は
> できたし（セグメントはイヤでしたが）、VUの最適
> 化も楽しめました。
私の場合、マシン語は Z80 -> 8068 -> 68k と経験
しましたが、68k に触れた時は目からウロコが落ちま
した（笑）。
> 個人主観ですが、見た目は重要だと思っています
> （速度重視の場合は仕方ないですが）。
メンテナンスを考えれば、ソースは読みやすいほうが
よろしいかと思います。
春麗さん、広井さん、こんにちは。
> そうですね。どの CPU にしても原理的には同じ（フォン
> ・ノイマン・アーキテクチャ）なので、ひとつの CPU で
> マシン語プログラムが組める人は、ほかの CPU でも何とか
> なるでしょう。
確かに、アーキテクチャが違っても基本的な考え方は
同じなので、何とかなる場合が多いと思います。
しかし、アーキテクチャにはそれぞれ個性があるので、
私はその個性を大事にしたいです。
プロセッサ関連のリンクを増やしているのは、
「プロセッサにはいろいろなアーキテクチャがある」
ということを知ってもらいたいためでもあります。
鎌田さん、こんばんは。
> > マシン語プログラムが組める人は、ほかの CPU でも何とか
> > なるでしょう。
>
> 確かに、アーキテクチャが違っても基本的な考え方は
> 同じなので、何とかなる場合が多いと思います。
> しかし、アーキテクチャにはそれぞれ個性があるので、
> 私はその個性を大事にしたいです。
そのとおりですね。コンパイラを使うにしても、最適化
技術が進歩しているとはいえ、使用する CPU のアーキ
テクチャを理解していないと、凄いプログラムは作れない
と思います。まあ、私が作るプログラムは軟弱なものばかり
なので、偉そうなことは言えませんが（笑）。
STUDIO KAMADA のリンク集は、プロセッサ関連のほかにも、
興味深いリンクが多いですね。画像検索エンジン Charlotte
は、画像ファイルのプレビューが表示されるので、とても
便利です。これからも期待しています。
それではまた。
広井さん、こんにちは。
> > しかし、アーキテクチャにはそれぞれ個性があるので、
> > 私はその個性を大事にしたいです。
>
> そのとおりですね。コンパイラを使うにしても、最適化
> 技術が進歩しているとはいえ、使用する CPU のアーキ
> テクチャを理解していないと、凄いプログラムは作れない
> と思います。まあ、私が作るプログラムは軟弱なものばかり
> なので、偉そうなことは言えませんが（笑）。
「アーキテクチャを知る必要がある」ということよりも、
単純に「このアーキテクチャを考えた人は凄い！って
思えるようなアーキテクチャがいろいろあって面白い」
という理由で、私はマイクロプロセッサのアーキテクチャ
に興味を持っています。
いずれは自分で設計してみたいし。
> STUDIO KAMADA のリンク集は、プロセッサ関連のほかにも、
> 興味深いリンクが多いですね。画像検索エンジン Charlotte
> は、画像ファイルのプレビューが表示されるので、とても
> 便利です。これからも期待しています。
ありがとうございます。
CharlotteはR.V.R.Homepageの
「ゲームプログラミング日記」で知りました。
私もロコちゃんは好きです。（笑）
265. IP接続サービス Hiroi Makoto 2000/10/15 (日) 22:55
265. IP接続サービス Hiroi Makoto ⌂ 2000/10/15 (日) 22:55 鎌田さん、こんばんは。
ＩＰ接続サービスで常時接続できない問題は、
Ｃマガジン８月号の「フィンローダのあっぱれご意見番」
にも書かれています。鎌田さんの日記を読んで思い出し
ました。フィンローダ氏は「１ヶ月ほどの間に２回経験
している」そうです。せっかくの常時接続サービスなの
ですから、きちんと対応してほしいですね。
それではまた。
広井さん、こんばんは。
> ＩＰ接続サービスで常時接続できない問題は、
> Ｃマガジン８月号の「フィンローダのあっぱれご意見番」
> にも書かれています。鎌田さんの日記を読んで思い出し
> ました。フィンローダ氏は「１ヶ月ほどの間に２回経験
> している」そうです。せっかくの常時接続サービスなの
> ですから、きちんと対応してほしいですね。
あ、やっぱり問題になっていますか。
356日接続しっぱなしにできるようにするためには
システムの保守のやり方を根本的に変えなければならず、
そこまで対応できていないということなのではないかと
思います。（憶測です）
そうでなければフレッツ・ISDNに対応したプロバイダが
これほど急激に増えるはずがありません。
結局、フレッツ・ISDNは、常時接続サービスではなくて、
単なる料金定額サービスらしい、ということで。
それにしても、接続がいきなり切れて困るのは従量制でも
定額制でも同じことなので、せめてどういう条件で切れる
のかはっきりさせて、接続開始から一定の時間は切れない
ようにするなどの工夫をして欲しいです。
まあ、今一番の不満は「64kは遅い」ということですけど。
もしかしたら公開機能だったかもしれませんが
ＬＥＤの明るさを調節するモードってありませんでしたっけ？
勘違いかな？
AC-YOUCHさん、こんにちは。
> もしかしたら公開機能だったかもしれませんが
> ＬＥＤの明るさを調節するモードってありませんでしたっけ？
キーボード制御コードの$54〜$57ですが、これはシャープが
資料を提供している「X68000データブック」に書いてあるので、
未公開ではないと判断しました。
他にも気付いたところがありましたら教えて下さい。
よろしくです。
275. いろんな仕様 LeDA 2000/10/19 (木) 10:33
275. いろんな仕様 LeDA 2000/10/19 (木) 10:33 ついでなので、バグに近い仕様に付いてもう1つ｡
Humanのファイル名比較は、標準では8+3バイトなので、
以下のようなファイル名は同じとみなされます｡
123456_８
123456_９
このとき、'８'は0x8257,'９'は0x8258なので、
8バイト目になる0x82までが一致しているので
同じと判定されるわけです｡ファイル名だけ見れば
絶対に違うはずなのになぜ一致してしまうのか、
昔これでえらく悩んでしまいました｡
TwentyOne導入後はなくなりましたが。
Human上では常識かもしれませんが、忘れている人も多いと
思いましたので一応書きました｡
・・・バグじゃないけど隠れ仕様みないな情報がいくつか
あるんですけど、そういうの書く気ないですか?＞Kamadaさん
LeDAさん、こんにちは。
> ・・・バグじゃないけど隠れ仕様みないな情報がいくつか
> あるんですけど、そういうの書く気ないですか?＞Kamadaさん
未公開機能は未公開機能として分類します。
「仕様なのかも知れないけれど、正しい挙動とは思えない」
というときは、「仕様バグ」として不具合情報に含めます。
「仕様バグ」かどうかは、独断と偏見も交えて判断します。
未公開機能がバグっているときは不具合情報にも入れます。
例えばMC68030のデータキャッシュのライトアロケーション
モードの変な挙動は、マニュアルに明記されていますが、
仕様バグだと思います。
すみません、このネタは昔書いた資料の中にあったものを
再検証せずに上げてしまいました｡
今再度調べたところ、
・画面右端で表示すると(0,y+1)とならず(画面幅,y)となる
・そのまま表示を続けると次の座標が(1,y+1)になる
でした(v1.2 ROMにて）。
B_LOCATEに(画面幅,y)を与えると無視されます｡
また、その位置で改行させたいときは0x0dのみでいけます。
（0x0aは不要｡)
情報は間違ってましたが、(0,y+1)が存在しないのはやはり
おかしいです｡
当時X1でも開発をよくしていたもので、このような座標の変化は
「バグ以外の何者でもない!!」と思っていたのでした｡
（X1ではちゃんと0,y+1になります。）
ということで、上げたものは間違いですので出来れば、
削除してください｡
LeDAさん、こんにちは。
> 今再度調べたところ、
> ・画面右端で表示すると(0,y+1)とならず(画面幅,y)となる
> ・そのまま表示を続けると次の座標が(1,y+1)になる
> でした(v1.2 ROMにて）。
画面の右端まで表示したときに、次の文字を表示するまで
改行を遅延させるのがX68000のIOCSの仕様なのだと思います。
コードを見ても、わざわざそうなるように書かれています。
少なくともコーディングのバグによる挙動ではありません。
そのような仕様になっている主な理由は、「画面の
右下隅に文字を表示しやすくするため」だと思います。
> B_LOCATEに(画面幅,y)を与えると無視されます｡
B_PUTCやB_LOCATEが(画面幅,y)を返すのに、
B_LOCATEにその座標を与えられないのは変ですね。
この点は仕様バグと言ってよいと思います。
> また、その位置で改行させたいときは0x0dのみでいけます。
> （0x0aは不要｡)
改行に限らず、カーソルが(画面幅,y)にあるときは
カーソルが(0,y+1)にあるときと同じ挙動をするように
作られています。
改行を遅延させているだけなのですから当然ですね。
> (0,y+1)が存在しないのはやはりおかしいです｡
> 当時X1でも開発をよくしていたもので、このような座標の変化は
> 「バグ以外の何者でもない!!」と思っていたのでした｡
> （X1ではちゃんと0,y+1になります。）
確かにカーソルが画面外の座標を示すのは不自然ですよね。
「画面の右下隅に文字を表示したいとき」以外に
これといった効能はなさそうですし。
未公開機能と仕様バグの分類に悩んでしまいます。
始めまして、TMKと申します。
サイバースティックの資料を探しているのですが、お持ちの方はいらしゃいますでしょうか？
アタリポートの信号制御方法とか、X68のレジスタの制御方法とか。。
始めまして、KQです。
満開ネットではレスありがとうございました。
>他にCで効率が悪くなることと言えば、「ローテート命令を
>使いたいとき」とか。
これは68000のGCC(1 〜2.6.3)での話ですよね？
最近のコンパイラならどのコンパイラでも
#define ROL(data,n,type) (data<<n|data>>(sizeof (type)*8-n))
#define ROR(data,n,type) (data>>n|data<<(sizeof (type)*8-n))
でローテート命令を出力できます。
（式がミスっていたらごめんなさい）
もちろん、GCC 2．95.2でも出力可能です。
シフト命令、ローテート命令の最適化テンプレートはかなり
増えているんで、以前に比べるとそこそこいいコードを出力
すると思います。
ごめんなさい、もっと楽に書けます。
#define ROL (data,n) (data << n | data >> (sizeof (data)*8 - n))
#define ROR (data,n) (data >> n | data << (sizeof (data)*8 - n))
ですね。ただし、dataは unsigned 型じゃないといけません。
すいませんでした。
KQさん、こんにちは。
> #define ROL (data,n) (data << n | data >> (sizeof (data)*8 - n))
> #define ROR (data,n) (data >> n | data << (sizeof (data)*8 - n))
>
> ですね。ただし、dataは unsigned 型じゃないといけません。
おお、確かにgcc2だとローテート命令になりますね。
ありがとうございます。
使うときは、マクロの名前の直後を詰めて、
式の中のdataやnは括弧で括っておくとよろしいかと。
Charlie版（2.6.3）では、16ビットローテートが
swapになりませんでした。2.95.2ではどうかな？
マクロの書き方にこだわってみました。:-)
/* ローテートマクロの定義（GCC用） */
/* dataはunsignedであること */
#define ROL(data,n) ({ \
typeof(data) _data_ = (data); typeof(n) _n_ = (n); \
(_data_ << _n_ | _data_ >> (sizeof(_data_)*8 - _n_)); })
#define ROR(data,n) ({ \
typeof(data) _data_ = (data); typeof(n) _n_ = (n); \
(_data_ >> _n_ | _data_ << (sizeof(_data_)*8 - _n_)); })
KAMADAさん、KQさん、こんにちわ。
gcc上でのローテート命令の生成は 以前某所とか某所で質問したり
自分で色々やってみたんですがうまくいきませんでした(^^;
singnedがらみかな？
結局その時は asm文でローテート命令を直接記述する方法をとりました(汗
ちょっと引っぱり出して書きなおしてみてみます。
AC-YOUCHさん、こんにちは。
> gcc上でのローテート命令の生成は 以前某所とか某所で質問したり
> 自分で色々やってみたんですがうまくいきませんでした(^^;
> singnedがらみかな？
signedだったか、GCCが真里子版だった、かな？
>
> signedだったか、GCCが真里子版だった、かな？
>
signedだと算術右シフト演算されてしまいますからね。
ashift命令が内部で生成されると思うのでローテート命令には
なりません。ローテートなら最適化しなくてもrotate,rotatert
が生成されると思います。こういうところは結構融通が利かないかもしれません。
高速インラインmemcpyルーチンを書いたときにちゃんと
型のサイズを判定してコピーするんでちょっとびっくりしました。
ソース上は4バイトごとにコピーしてるのに元がchar型だと1
バイトずつコピーするっていう感じです。
インテルCPUだとこのサイズもできるだけ4バイトずつコピーするように最適化してしかもスーパースカラースケジューリングします。
くやし〜(T^T;
ただし、そういうソースを書かなければいけないのだけど・・・。
KQさん、こんにちは。
> 高速インラインmemcpyルーチンを書いたときにちゃんと
> 型のサイズを判定してコピーするんでちょっとびっくりしました。
> ソース上は4バイトごとにコピーしてるのに元がchar型だと1
> バイトずつコピーするっていう感じです。
68000のアドレスエラーを避ける仕掛けが働いて
いるから？
68000のときはソースとデスティネーションの
アドレスの奇遇が一致しているときと一致して
いないときで分けて、一致しているときだけ
ロングワード転送に。（常套手段）
> インテルCPUだとこのサイズもできるだけ4バイトずつコピーするように最適化してしかもスーパースカラースケジューリングします。
> くやし〜(T^T;
GCCの最適化は、68K用の最適化のノウハウが他の
アーキテクチャにも活用されていると聞いたことが
あります。
でもスーパースカラのスケジューリングに関しては
68K以外のアーキテクチャのほうが対応が進んでいる
のでしょうね。
> ただし、そういうソースを書かなければいけないのだけど・・・。
結局、Cのソースを書く人間がコンパイル結果を
予測できるようでないと、コンパイラの最適化は
最高の結果をもたらすことができないと思います。
最適化が最高の結果でなくても多くの人は満足して
しまいますが、私は満足できない人です。
> 68000のアドレスエラーを避ける仕掛けが働いて
> いるから？
> 68000のときはソースとデスティネーションの
> アドレスの奇遇が一致しているときと一致して
> いないときで分けて、一致しているときだけ
> ロングワード転送に。（常套手段）
>
インラインアセンブラを使っているわけではないので、
ソース上はそうなっているんですが・・・。
>
> GCCの最適化は、68K用の最適化のノウハウが他の
> アーキテクチャにも活用されていると聞いたことが
> あります。
GNUツールは元々Motrola 68000シリーズとナショナル
セミコンダクタの32000シリーズをベースにサポートされる
ので68000のコードの出力は多分一番最初のGCCからあった
はずです。たぶんそれをもとにいろいろなCPUへ移植された
のでしょう。
>
> 結局、Cのソースを書く人間がコンパイル結果を
> 予測できるようでないと、コンパイラの最適化は
> 最高の結果をもたらすことができないと思います。
> 最適化が最高の結果でなくても多くの人は満足して
> しまいますが、私は満足できない人です。
効率、移植性や再利用が必要かどうかなどによるでしょう。
私にいわせるとC++はいらないとなってしまいますしね(^^。
OOPをしたいならシンプルなObjective Cで十分ですから。
でも、「選択肢は多い方がよい」というのが私の最終的な結論です。
KQさん、こんにちは。
> インラインアセンブラを使っているわけではないので、
> ソース上はそうなっているんですが・・・。
(char)→(int)のキャストが効かないということ？
やはりGCCのアドレスエラーを避ける仕掛けが強すぎるのかな？
> > 最適化が最高の結果でなくても多くの人は満足して
> > しまいますが、私は満足できない人です。
>
> 効率、移植性や再利用が必要かどうかなどによるでしょう。
効率、移植性や再利用を考えても、「どこで満足するか」
ではなくて「どこで妥協するか」になってしまうのが
私の性分でして。不便な性分（笑）です。
> 私にいわせるとC++はいらないとなってしまいますしね(^^。
> OOPをしたいならシンプルなObjective Cで十分ですから。
> でも、「選択肢は多い方がよい」というのが私の最終的な結論です。
そうですね。選択肢が多いのはよいと思います。
好きな選択肢が消えてゆくのは寂しいです。
ご指導ありがとうございます(^^。まさにそのとおりです。
>Charlie版（2.6.3）では、16ビットローテートが
>swapになりませんでした。2.95.2ではどうかな？
ちゃんとswapを出力しますにょ。さすがに同じバージョンの
GCCのインテルCPUの最適化にはとてもかないませんが・・・。
ちなみに、もうG++も Objective Cもうごいてます。
(どっちも約一日で移植できました。)
あとは実機に持っていかなければいけないのですが、
Cを移植するときよりは大変ではないんですぐ動くと思います。
Javaはやっぱり難しいかなという感じです。コンパイラは
ともかくlibgcj.aを書いてくれる人がいないんで。
OSの仕様とか、POSIXスレッドとか、GCとか・・・。
KQさん、こんにちは。
> ご指導ありがとうございます(^^。まさにそのとおりです。
あ、あれは、読んでいただいている皆さんのために
補足として書かせていただきました。
それから、説明を忘れてしまいましたが、マクロを
書き換えたのはROR(*p++,1)のような場合に副作用
のある引数が2回評価されないようにするためです。
この手の原因のバグは発見しにくいので予防策です。
> ちゃんとswapを出力しますにょ。
えらいにょ。
> さすがに同じバージョンの
> GCCのインテルCPUの最適化にはとてもかないませんが・・・。
稼動実績が多いと進歩も速いのでしょうね。
> ちなみに、もうG++も Objective Cもうごいてます。
> (どっちも約一日で移植できました。)
> あとは実機に持っていかなければいけないのですが、
> Cを移植するときよりは大変ではないんですぐ動くと思います。
もう慣れちゃってるって感じなのかなぁ。すごいです。
私は古いGCCのDSP56K用のソースを拾ってきてcc1だけ
X68kで動かしたことがありますが、最近のは複雑で…。
> Javaはやっぱり難しいかなという感じです。コンパイラは
> ともかくlibgcj.aを書いてくれる人がいないんで。
> OSの仕様とか、POSIXスレッドとか、GCとか・・・。
OSの仕様といっても、「そもそもOSの機能が少なすぎる」
なんてことになったりしないかな。
Kamadaさんどうも
>
> もう慣れちゃってるって感じなのかなぁ。すごいです。
> 私は古いGCCのDSP56K用のソースを拾ってきてcc1だけ
> X68kで動かしたことがありますが、最近のは複雑で…。
>
DSP56Kって最近のリリースには含まれてません。
もしあるとしたらどこにありますか?
(dsp16xxならあるけど・・・)
>
> OSの仕様といっても、「そもそもOSの機能が少なすぎる」
> なんてことになったりしないかな。
どうなんでしょう?FreeBSDでもソースにぱっちをあてないと動か
ないくらいなので現状ではGCJはLinuxしかサポートしていないん
でしょう。
KQさん、こんにちは。
> DSP56Kって最近のリリースには含まれてません。
> もしあるとしたらどこにありますか?
> (dsp16xxならあるけど・・・)
MotorolaがポートしたGCCなので、マイナーなバージョン
なのだと思います。MAC命令や並列転送も吐きます。
Googleなどで「DSP56K GCC」を検索すれば出てきます。
http://www.idiom.com/free-compilers/
から辿るのがわかりやすいかも知れません。
2月24日の日記も参照されたし。
鎌田さん今晩は はんかつです。
皆さんお忙しいようなので書かせていただきます。
サイバースティックの資料ですが、
Oh!X 1989年7月号C調言語講座PRO-68K
「サイバースティックを使うのである」に載っております。
電脳倶楽部にものったはず。
補足が、Oh!X 1990年5月号ラジコンスティックの製作及び
outside X68000に掲載されています。
はんかつさん、こんにちは。
> 皆さんお忙しいようなので書かせていただきます。
> サイバースティックの資料ですが、
> Oh!X 1989年7月号C調言語講座PRO-68K
> 「サイバースティックを使うのである」に載っております。
> 電脳倶楽部にものったはず。
Oh!X 1989年7月号、確認しました。
故・祝一平氏の小気味良い文章に見覚えがありました。
> 補足が、Oh!X 1990年5月号ラジコンスティックの製作及び
> outside X68000に掲載されています。
補足情報まで確認ありがとうございます。
こちらは桑野さんが書かれていますね。
Oh!X持ってるかな？＞TMKさん
みなさんはじめまして。
資料ですが、電クの拾四號にありました。(AJOY.Xのソース付き)
バイナリだけでもよければアフターバーナーにもおまけで入っています…。
あと、すぐ手に入る範囲では、田圃さんのページにサイバーマウスのドライバがあったはずです。（使用目的が違うので一部省略されているかもしれませんが）
# どうでもいいんですが、AJOY.FNCは見つかりませんでした。（たしかこれもAJOY.XのIOCS $F2を使わずに自前で操作していたはず…）
morさん、こんにちは。
> 資料ですが、電クの拾四號にありました。(AJOY.Xのソース付き)
月刊電脳倶楽部14号、確認しました。
（パーフェクトコレクション1に入っています）
アナログジョイスティックドライバAJOY.Xと、そのソースと、
技術資料が載っていますね。
「シャープ提供」ということですが、パブリックドメイン
になっているので、あとで転載しておきますね。＞TMKさん
297. サイバーの事 TMK 2000/10/24 (火) 15:16
297. サイバーの事 TMK 2000/10/24 (火) 15:16 はんかつさん、morさん、M.Kamadaさんレスありがとうございます。
＞Oh!X持ってるかな？＞TMKさん
Oh!Xは毎月買っていたのですが、既に手元にはないのでした。(^^;
技術資料よろしくお願い致します。＞M.Kamadaさん
TMKさん、こんにちは。
> 技術資料よろしくお願い致します。＞M.Kamadaさん
ダウンロードのページに置いておきましたのでどうぞ。
M.Kamadaさん、こんばんわ
> > 技術資料よろしくお願い致します。＞M.Kamadaさん
>
> ダウンロードのページに置いておきましたのでどうぞ。
ありがとうございます！ 頂いて参ります。
また、レスを頂きました皆様、本当にどうもありがとうございました。
鎌田さん、掲示板の皆さん、こんにちわ。
実はタイトル通りの事情でして、
満開ネットに詳しい方にお聞きしたいんですが
満開ネットって telnet経由でも見れましたか？
あと、パスワードを忘れてしまった時は
どうすれば良いんでしょうか？
ZooMarkさん、こんにちは。
> 実はタイトル通りの事情でして、
> 満開ネットに詳しい方にお聞きしたいんですが
> 満開ネットって telnet経由でも見れましたか？
telnetでは入れないでしょう。
普通の電話回線にモデムとX68kが繋がっているだけ
のはずです。
> あと、パスワードを忘れてしまった時は
> どうすれば良いんでしょうか？
ゲストで入るか誰かに頼んでシスオペに言うしか。
ホストが移転したあと、私は満開ネットにログイン
できずにいます。いつも話し中で。
（満開ネットの移転については10月13日の日記を参照）
鎌田さん、こんばんわ。
回答ありがとうございます。
やっぱりモデムをつなげないと駄目なんですね。
もし中に入れたら、パスワードの事はシスオペに聞いてみます。
どうも失礼しました。