[Proposal] newgroup fj.comp.lang.asm.{x86, misc}
HIRAO
message news:38B1560D...@mail.ecc.u-tokyo.ac.jp...
> いいじま＠東大文学部です。
>
> ＃このグループ（たとえば fj.os.linux とか fj.unix とか、
> ＃あるいは fj.comp.lang.{pascal, visualbasic} とか）を足せ、
> ＃これは要らないから外せ、等あればご指摘ください。
> ＃
> ＃また、手続き上は必ずしも必要ではありませんが、委員会にも
> ＃メールで送っています。
反応がないですね（＾＾；； と言うことで宣伝が必要なようですので、
Followupを無視して、自分なりに普段読んでいるプログラム系のグループと、
あと必要だと思われるグループを選んでみました。
> そろそろ喪が明けるので、アセンブラに関するニュースグループを
> 再提案したいと思います。
喪ってなんでしょうか（＾＾；
> ＃私が提案するのははじめてなので、とりあえず proposal です。
> ＃あるていど反応をみてから CFD に移りたいと思います。
>
> 【需要について】
>
> 需要はそれなりにあると思います。C 言語の言語仕様の話題
> などからアセンブラの話に発展することがしばしばありますし、
> comp.lang.asm.x86 や microsoft.public.masm にそれなりの
> 投稿があることから考えて、日本語のグループがあってもいい
> と思います。
そうですね、僕の場合は最近ですが、fj.comp.lang.c++でC++から
の最適化でそう言う話題がありアセンブラーを使えるようになりました。
あと、リアルタイムで動く必要がある、マルチメディア系で必要
な技術ではないかと思います。
> 前回は否決されましたが、これは、アセンブラのグループの
> 可否自体が問題にされたのではなく、手続き上の問題が主で、
> アセンブラのグループ自体の可否に関する議論はほとんど
> なかったと記憶しています。
どう言った問題だったのでしょうか？ 日付を教えていただけると
検索に役立つと思うのですが…
> 【グループの構成について】
>
> とりあえず、80x86 の話題は多発すると思われます。たとえば、
> MS-DOS プログラミングとか、Windows API 利用上の問題とか。
> ひょっとしたら、Linux のカーネルソースの話なども出てくる
> かもしれません。
>
> そこで、80x86 は分離したいと思いますが、それ以外のアセン
> ブラの需要もないわけではないと思うので、とりあえず、ふたつ
> 提案したいと考えます。
イヤ、今回反応がないことを見れば分かりますが、分離は必要ない
のではないかと…
> fj.comp.lang.asm.misc（.misc を取った形も考慮中）
> その他のアセンブリ言語に関する議論。
> Discussion about miscellaneous assembly languages.
fj.comp.lang.asmが理想かなっと思いますが…
NetNewsになれていない人にはmiscが分かりにくいかもしれないし…
> fj.comp.lang.asm.x86
> 80x86 のアセンブリ言語に関する議論。
> Discussion about 80x86 assembly language.
流量が多くて混乱するというのでしたら分けた方が良いと思いますが、
パソコン用にプログラムの開発と言うことであれば、８６系から、Ｍａｃ用
まで話題が拡大した方が良いと思いますので、分けてしまうのは逆効果では
ないかと思います。
それに実用だけでなく、非商用でないといけないと言うfjでは、好奇心的
な話題で盛り上がったり読めたりした方が良いのではないかと思います。
好奇心と言うことでは異なるCPUの話題というのはおもしろいと思うのですよね…
変な話、インテル系とＭａｃ系でフレームになるようなことがあった方が
おもしろいかもしれないです（＾ー＾；；
あまり流れないニュースグループに投稿をするのは不安ですから、
けっきょくは他のグループにクロスポストする事になるかもしれませんし、
流量の少ないグループをチェックするのも空しいですし（＾＾；
とりあえず、分けておいた方が良いことがあらかじめ推測できていないのなら、
一つにまとめておいた方がいろいろ良いのではないかと思う。
> 【80x86 と Micsosoft 系 OS の関係について】
>
> x86 のほうでは MS-DOS、Windows の話題が主になると考えられ
> ますが、べつにそれに限る必要もないと思いますし、Linux や
> 組み込み環境などの話題がくることも想定しています。
特定ＯＳの話題で良いのなら最初からそこでしょうと言うことに
なりかねませんから、アセンブラーの話題は流量が少ない場合に限り
ごった煮にしておいた方が良いのでは・・・
Shinji KONO
In article <890kni$hef$1...@www5.net0726.ne.jp> ,
"HIRAO" <hi...@ns2.net0726.ne.jp> writes
> 反応がないですね（＾＾；； と言うことで宣伝が必要なようですので、
>Followupを無視して、自分なりに普段読んでいるプログラム系のグループと、
>あと必要だと思われるグループを選んでみました。
asm は賛成です。ないと、fj.comp.arch を使いますので困っていはいませんけど。
> 喪ってなんでしょうか（＾＾；
僕があるいた後には喪ができる。僕の前には喪はない。
(死んだらの間違いじゃないのかってのは却下)
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
KISHIMOTO Shinsuke
From: "HIRAO" <hi...@ns2.net0726.ne.jp>
Date: Wed, 23 Feb 2000 21:38:57 +0900
Subject: Re: [Proposal] newgroup fj.comp.lang.asm.{x86, misc}
Newsgroups: fj.comp.lang.c,fj.comp.lang.c++,fj.news.group.comp,fj.os.ms-windows.programming,fj.sys.mac.programming
Message-ID: <890kni$hef$1...@www5.net0726.ne.jp>
>> そろそろ喪が明けるので、アセンブラに関するニュースグループを
>> 再提案したいと思います。
>
> 喪ってなんでしょうか（＾＾；
同じCFDを乱発するのを防ぐために、前のCFDが出されてから3か月
は、同じニュースグループに対するCFDは出せなくなっています。
この3か月がたって、新しくCFDが出せる状態になることを、「喪が
明ける」と表現している人がいる、ということです。
--
○copyright
著作権、あるいは複製権。音楽や映画、ソフトウェアなどの著作物に
対する権利の一つ。
～私家版fj用語集より～ http://www3.justnet.ne.jp/~s_kishimoto/
IIJIMA 'Delmonta' Hiromitsu
＃Mac は知らないもので、fj.sys.mac.programming はすっかり忘れて
＃おりました。次の CFD 告知記事からはきちんと入れるようにします。
> > そろそろ喪が明けるので、アセンブラに関するニュースグループを
> > 再提案したいと思います。
>
> 喪ってなんでしょうか（＾＾；
俗語を使ってしまって申し訳ありません。
岸本さんに解説していただいたとおりです。
> そうですね、僕の場合は最近ですが、fj.comp.lang.c++でC++から
> の最適化でそう言う話題がありアセンブラーを使えるようになりました。
>
> あと、リアルタイムで動く必要がある、マルチメディア系で必要
> な技術ではないかと思います。
はい。マルチメディアがらみというと、スピードの点以外にも、Intel で
いうと MMX のような、多ビット並列演算機構の話もおもしろそうです。
> > 前回は否決されましたが、これは、アセンブラのグループの
> > 可否自体が問題にされたのではなく、手続き上の問題が主で、
> > アセンブラのグループ自体の可否に関する議論はほとんど
> > なかったと記憶しています。
>
> どう言った問題だったのでしょうか？ 日付を教えていただけると
> 検索に役立つと思うのですが…
前回の提案は、
提案者：河野真治さん <ko...@ie.u-ryukyu.ac.jp>
提案日：1999 年 11 月 20 日
です。
河野さんの提案は、手元のサーバーにあるものでは
12 月 3 日づけ <5881.94...@rananim.ie.u-ryukyu.ac.jp>
からたどれるスレッドがあります。
最終的な管理人裁定は、
1 月 25 日づけ <86kga4$gtr$3...@meshsv230.tk.mesh.ad.jp>
です。
＃で、よく調べてみたら「そろそろ喪が明ける」といっておきながら、
＃すでに明けてたんですね…
> > そこで、80x86 は分離したいと思いますが、それ以外のアセン
> > ブラの需要もないわけではないと思うので、とりあえず、ふたつ
> > 提案したいと考えます。
>
> イヤ、今回反応がないことを見れば分かりますが、分離は必要ない
> のではないかと…
（略）
> 流量が多くて混乱するというのでしたら分けた方が良いと思いますが、
> パソコン用にプログラムの開発と言うことであれば、８６系から、Ｍａｃ用
> まで話題が拡大した方が良いと思いますので、分けてしまうのは逆効果では
> ないかと思います。
>
> それに実用だけでなく、非商用でないといけないと言うfjでは、好奇心的
> な話題で盛り上がったり読めたりした方が良いのではないかと思います。
> 好奇心と言うことでは異なるCPUの話題というのはおもしろいと思うのですよね…
> 変な話、インテル系とＭａｃ系でフレームになるようなことがあった方が
> おもしろいかもしれないです（＾ー＾；；
（略）
> とりあえず、分けておいた方が良いことがあらかじめ推測できていないのなら、
> 一つにまとめておいた方がいろいろ良いのではないかと思う。
なるほど。それもおもしろいですね。
ということで、
○今回は fj.comp.lang.asm のみ提案
○しばらく様子を見て、もし特定のプロセッサの話が増えて
くるようならば、そのときに分割
ということでいいでしょうか。
＃あとは憲章をどう書くかだ。
☆-- 飯嶋 浩光 ----------------------------------------------☆
｜IIJIMA 'Delmonta' Hiromitsu an der Universitaet Tokyo ｜
☆-----------------------------------------------------------☆
｜ODN ユーザーは odn.question を購読しましょう。 ｜
☆-----------------------------------------------------------☆
｜【宣伝】Windows 95/98 管理人のための MS-DOS 基礎講座 ｜
｜ http://user.ecc.u-tokyo.ac.jp/~l94102/dos/ ｜
☆-------------------------- L94...@mail.ecc.u-tokyo.ac.jp --☆
c.g.green
みなさん、こんにちは。
> イヤ、今回反応がないことを見れば分かりますが、分離は必要ない
> のではないかと…
僕も分離は必要ないと思います(^_^;)。話の流れでアセンブラと言うより_asmの
話になりましたが、アセンブラに話の流れが移ったからとはいえその度にいちいちグ
ループを渡り歩くのは(^_-)なんか違うような気がするし(^_^;)。
Shin Miyazaki
cg_...@osa.att.ne.jp writes:
<89506j$psj$1...@newsflood.osaka.att.ne.jp>の記事において
"c.g.green"さんが書いたことについて、
>> 僕も分離は必要ないと思います(^_^;)。話の流れでアセンブラと言うより_asmの
>> 話になりましたが、アセンブラに話の流れが移ったからとはいえその度にいちいちグ
>> ループを渡り歩くのは(^_-)なんか違うような気がするし(^_^;)。
違わないでしょう。
少なくとも fj.comp.lang.c(++) で80x86用のアセンブラの話を延々と
続けられるのは迷惑です。
--
宮崎辰
sh...@est.co.jp
IIJIMA 'Delmonta' Hiromitsu
清水さんの記事が fj.os.ms-windows.programming にしか出ていないので、
元のグループ群を追加し、あらためて followup-to を fj.news.group.comp
にします。
> 個人的には分離には反対です。
> 理由はアセンブリ言語とかは単体で議論するような対象でなく、何々に絡んで
> といったシステムなりなんなりの前提が必要だからです。
はい。
ところで、念のため確認したいのですが、この「分離には反対」という
のは、x86 と misc の分離に反対ということでよろしいでしょうか？
（asm を作ること自体に反対、となると意味が全然違ってきますので。）
> windowsに絡んだ話はwindowsの所ですればいいし、linuxに絡んだ話は
> linuxの所ですればいいんじゃないですか？
はい。
ここが微妙なところなのですが、そういう専用のグループで話ができる
ようなプラットフォームって、私の知る限りでは、Windows と Mac しか
ないんです。fj.os.ms-windows.programming や fj.sys.mac.programming
で、Windows/Mac における 80x86 アセンブラや 680x0/PowerPC アセンブ
ラの話をするのはもちろんいいのですが、たとえば
(1) fj.sys.sun で SPARC アセンブラの話をする
(2) fj.sys.{ibmpc,pc98} で AT/98 の BIOS の叩き方の話をする
(3) fj.os.msdos で、int 24H をトラップ云々という話をする
のは気が引けます。
＃個人的には (3) が今回の提案の大きな動機なのですが、これは (1)(2)
＃と比べると深刻度は低いかな？ (1) は fj.comp.arch を使うという手が
＃ありますが、(2) は fj.sys.ibmpc も fj.os.msdos もちょっと…と
＃なります。たとえば、いま話題だと、MBR のパーティションテーブルが
＃壊れたときの処方箋のひとつとして「Win9x の起動ディスクで DOS を
＃起動し、debug.com でint 13H を叩く」というのがあがっていますが、
＃これの突っ込んだ話は asm が適当だと思います。
で、アセンブラの話となると fj.comp.lang.c(++) からの派生が増えて
きます。たとえば、
○関数呼び出し時に引数はどう渡されるのか、返り値はどう
返ってくるのか。たとえば、math.h なしで sqrt(2) と書くと、
（つまり、int sqrt(int) という暗黙の宣言をすると）結果は
どうなるのか。（結論から言うと、スタック上のデータが破壊
される実装もあります）
○NULL ポインタの内部表現が 0 でない場合でも (void *)0 は
NULL ポインタになるはずだ、その実例・実装は云々…
○「Win32 にある FAR キーワードって何？」「それは Win16 の
名残で、80286 っていうプロセッサはね…」
といった話です。このへんの話ができるグループがあればおもしろいと
思います。
＃あまり調べていませんが、関数呼び出しの実装方法などは Win32 でも
＃Linux や FreeBSD などでも同じだと思うので、アセンブラということで
＃まとまったグループができれば有益な議論ができると思います。
あるいは、さいきん fj.comp.oldies であった 6809 と 8086 の乗算回路の
比較などもここでできればおもしろいと思います。