68k v.s. x86 Round 3

1 ：ナイコンさん：2016/03/20(日) 14:15:55.28 .net

16Bitパソコン時代のMPU/CPU 68kとx86を語るスレです。
68020,386以降の32BitやZ8kや658xxの話題もOKです。

過去スレッド
68k v.s. x86 Round 2
http://hanabi.2ch.net/test/read.cgi/i4004/1455196631/

68K v.s. x86
http://hanabi.2ch.net/test/read.cgi/i4004/1220728356/

709 ：ナイコンさん：2016/05/20(金) 12:41:58.99 .net

普通に素直に設計すればリトルになるよ。
素子が真空管やリレーな時代は知らんが。

710 ：ナイコンさん：2016/05/20(金) 12:44:23.95 .net

ビッグエンデアンの利点は真面目に、バイト単位でダンプしたリストが読みやすいのひとつだけだからなぁ。

711 ：ナイコンさん：2016/05/20(金) 12:47:34.08 .net

そしてリストエンデアンの欠点はバイト単位のダンプが、ビッグのそれと比べれば少しばかり読みにくいというそれだけしかない。

712 ：ナイコンさん：2016/05/20(金) 13:00:07.26 .net

無駄なおマヌケ話だねw

713 ：ナイコンさん：2016/05/20(金) 13:03:29.48 .net

>>698
> 型変換だけしたもりなのに、

エンディアンに依存したコード書くお前がマヌケなだけ。

714 ：ナイコンさん：2016/05/20(金) 13:08:42.54 .net

>>708
ビッグエンディアンでアラインがめちゃくちゃだと
例えば下位バイトのポインタが型によって違うとかになるから
8bit値だろうが32bit値だろうが必ず32bitアラインで配置してあればいいけど

715 ：ナイコンさん：2016/05/20(金) 13:37:49.57 .net

SHIFT-JISコードの処理をするときに
リトルだとバイトスワップが必要だったのが気になった（というか違いを感じた）くらいかな。
それ以外はリトルでもビッグでも違いは無い気がする。

716 ：ナイコンさん：2016/05/20(金) 14:33:30.49 .net

ワイド文字コードとかRGBAとかがひっくり返るのが罠
バイトワードを混在させる場合はビッグエンディアンのほうがやりやすいよね

717 ：ナイコンさん：2016/05/20(金) 15:55:45.82 .net

>>706
ハード設計したことのない無能の妄想乙

718 ：ナイコンさん：2016/05/20(金) 20:07:40.23 .net

文字列みたいなバイトストリームはビッグもリトルも手間はたいして違わないだろ。

719 ：ナイコンさん：2016/05/20(金) 20:18:25.24 .net

ポインタ経由でサイズの違う型にキャストして中身壊れんリトルと、壊れることもあるビッグと、どっちが優れてるか一目瞭然。

720 ：ナイコンさん：2016/05/20(金) 21:24:09.71 .net

たとえば渡されたポインタの値をそのまま返すだけの
void* func(int *i)
{
return i;
}
なんて関数がある。

これで
int i=0x12345678;
printf(

721 ：ナイコンさん：2016/05/20(金) 21:49:46.57 .net

> ポインタ経由でサイズの違う型にキャストして中身壊れんリトルと、壊れることもあるビッグと、どっちが優れてるか一目瞭然。

↑キャストを理解してない模様

722 ：ナイコンさん：2016/05/20(金) 22:01:11.50 .net

>>713
エンディアンに依存しないコード書いてるアホなんているの？
それっていつも処理系依存しないコード書いてるってことでしょ。
テスト環境もない処理系のためにコード書いてもテストできない。
つまりキミはいつもそんな未テストコードを含んだものをリリースしてるのかい？

723 ：ナイコンさん：2016/05/20(金) 22:18:29.97 .net

>>722
例えば32ビット値を8ビット×4でアクセスする場合、
ポインタのキャストやunionを使うとエンディアン依存になるけど、
真っ正直にシフトと&を使えばエンディアンに依存しなくなる。

そういうことを言ってるんじゃないかな？

724 ：ナイコンさん：2016/05/21(土) 00:54:26.41 .net

>>722
処理系依存しないコードはむしろテスト環境を選ばないんだが?

725 ：ナイコンさん：2016/05/21(土) 01:23:21.93 .net

未だにそんなファンタジーなこと言われてもな。
Javaで散々、Write Once, Debug Everywhere. って言われてたのに。
Cのライブラリでさえ、ビッグエンディアンとリトルエンディアンで微妙に挙動が違う。

テストしないで想定どおり動くとか妄想にすぎない。神にでもなったつもりか。

726 ：ナイコンさん：2016/05/21(土) 01:28:06.71 .net

> テストしないで想定どおり動くとか妄想にすぎない。

このスレで誰かそんなこと言ってるかな?

727 ：ナイコンさん：2016/05/21(土) 01:30:24.89 .net

エンディアンに依存したコードを日常的に書いてる人はテストの効率も悪そう。
書いてるソースもキャストとか使いまくってそう。

728 ：ナイコンさん：2016/05/21(土) 01:31:39.93 .net

>>726
おまえだよw

729 ：ナイコンさん：2016/05/21(土) 03:25:38.42 .net

>>728
藁人形論法とはお里が知れますねｗ

730 ：ナイコンさん：2016/05/21(土) 03:48:36.08 .net

結局「リトルエンディアン信者は低脳」という事実を証明し続けてるんだよなあ

731 ：ナイコンさん：2016/05/21(土) 03:58:30.60 .net

すげー。ビッグエンディアンを肯定してる人がまだこの世にいたんだ。前世紀に絶滅したと思ってたよ。

732 ：ナイコンさん：2016/05/21(土) 05:32:58.44 .net

そもそも >>722 の論理が意味不明
処理系依存しないコードを実際に使う処理系でテストして出すだけだろ？

733 ：ナイコンさん：2016/05/21(土) 05:34:08.43 .net

すげー。エンディアンにこだわってる人がまだこの世にいたんだ。前世紀に絶滅したと思ってたよ。

734 ：ナイコンさん：2016/05/21(土) 06:01:03.30 .net

>>727
ネットワーク系とデバイスドライバは、どうやっても、エンディアンに依存するだろ。

735 ：ナイコンさん：2016/05/21(土) 06:04:44.08 .net

>>732
つまりテストするまで依存してるかしてないか分からない。
でも本人は依存してないコードを書いてると思ってる。そういうのを妄想って言うんだよ。

736 ：ナイコンさん：2016/05/21(土) 06:05:02.30 .net

ビッグエンディアン信者はキチガイってよくわかるスレだｗｗｗ

ビッグエンディアンなんて利点なんて何ひとつ無いのになぁ。
この世にビッグエンディアンが生まれたのは「ハード屋がソフトのことをまったく考えないで手抜き設計した結果」「設計者の自慰」とか言っても過言じゃないだろ。

737 ：ナイコンさん：2016/05/21(土) 06:20:39.36 .net

エンディアン、嘘つかない。
玉子は真ん中から食べる

738 ：ナイコンさん：2016/05/21(土) 06:27:06.61 .net

>>737
ラピュータ人もびっくり！

真ん中からってことはレジスタで0x12345678をメモリに置くと0x34 0x56 0x12 0x78 とか、0x56 0x12 0x34 0x78 見たいになるのかな。

739 ：ナイコンさん：2016/05/21(土) 07:58:04.40 .net

このスレに粘着してる86上げ68下げ君は無能過ぎて86のネガキャンになってるからもうやめとけw

740 ：ナイコンさん：2016/05/21(土) 07:59:36.85 .net

マカーと言ってることが似てるw

741 ：ナイコンさん：2016/05/21(土) 08:13:07.52 .net

>>735
ますます意味不明 w

> つまりキミはいつもそんな未テストコードを含んだものをリリースしてるのかい？
まあとりあえず、これにごめんなさいするところから始めようか

742 ：ナイコンさん：2016/05/21(土) 08:31:46.07 .net

技術的な反論は一切なく、罵倒し、謝罪しろ。隣国の方ですね。

743 ：ナイコンさん：2016/05/21(土) 08:54:56.38 .net

386はフラットメモリになったんじゃなくて、セグメントリミット取っ払ったんだよ。
んで、セグメントが変わると別なマックス4Gの空間にアクセスする。
見た目はメッッチャ広いメモリ空間。


なんで286ん時にセグメントディスクリプタを32ビットにしておかなかったんだろうなー。
予約領域とか言ってても32ビットで使うって決めてあったんだろうし。

744 ：ナイコンさん：2016/05/21(土) 09:00:06.98 .net

ビッグエンディアンの技術的な利点が全く書かれてないな。
でもリトルエンディアンを貶すことだけは忘れないのw

745 ：ナイコンさん：2016/05/21(土) 09:01:36.12 .net

間違ったことを言ったんだから訂正しなよ
ってだけのこと
小学生でもわかる話

746 ：ナイコンさん：2016/05/21(土) 09:53:42.11 .net

>>734.744

TCP/IPネットワークでは、エンディアンの異なるコンピュータ間での通信を可能とするため、
パケットなどに含まれる多バイトデータはビッグエンディアンに統一することと決められている。
これをネットワークバイトオーダという。これに対し、それぞれのコンピュータ上での
エンディアンのことをホストバイトオーダという。

747 ：746：2016/05/21(土) 10:30:52.57 .net

ちなみに、Intelが強く絡んでたUSBは規格的にリトルエンディアン基準だねw

748 ：ナイコンさん：2016/05/21(土) 10:31:42.43 .net

ネットが遅いのはモトローラのせいか!!!

749 ：ナイコンさん：2016/05/21(土) 10:32:08.31 .net

>>746
通信で受信する側がアドレスの上位から受け取る利点は良く判る。
特にハブ見たいな中継装置はアドレス部分を受信した時点で後続データ受信中でも転送先が決定できてスループット向上につながったりするから。
でもそれは「装置間のデータ通信」での利点で、CPUのレジスタとメモリの間の話じゃないぞ。

750 ：746：2016/05/21(土) 10:35:14.72 .net

もう一個、Appleが強く絡んでいたfirewire(IEEE1394)はビッグエンディアン基準。
この種の規格は原開発会社の意向が強く反映しちゃうわけです。

751 ：ナイコンさん：2016/05/21(土) 10:40:37.08 .net

通信はヘッダから送るんだから、アドレスがビッグでもリトルでもスループット変わらないんじゃないのか。

752 ：ナイコンさん：2016/05/21(土) 10:45:37.49 .net

>>749
> でもそれは「装置間のデータ通信」での利点で、CPUのレジスタとメモリの間の話じゃないぞ。

リトルエンディアン固定頭のIntel cpuでビッグエンディアン変換処理が手間でロスタイムを
生じるのは技術仕様だから仕方ないことだろうね。8080/8086が特権命令やオペランドで
エンディアン指定できたりしていればより汎用性が高まっていたかもしれんね。

753 ：ナイコンさん：2016/05/21(土) 10:47:57.66 .net

>>751
パケットとは何であるか。今からでも学習した方がいいと思うよ。

754 ：ナイコンさん：2016/05/21(土) 10:58:01.41 .net

>>753
ネスペなら持ってるで。

755 ：ナイコンさん：2016/05/21(土) 11:10:56.11 .net

日本マイクロソフト人事本部シニアマネージャー（名ばかり管理職）の西川昌邦（さいかわまさくに）は犯罪者にして殺人犯だ！！
「あなたのような従業員は会社のパフォーマンスにとってマイナスなので早く死んでください」
などと自殺教唆を公然と行った！！ その結果人が死んだ！！
丁寧に言えば何を言ってもいいというものではない！！これはヤクザや借金取りが脅迫をする時に
「いついつまでに金一億円をお振り込みください。命が惜しければ間違った判断をなされないことを期待します」
と発言するのと同じレベルだ！！
しかもそれを注意してやったら、「世間はわれわれの味方だ。文句があるなら訴えてきたらよろしい。メールを電番を公開したければ
どうぞご自由に。世論はわれわれを賛辞するするメールを送付するだろう」
などとイカ様気取りも大概にしろという発言を行った！！
抗議先 日本マイクロソフト人事本部　西川昌邦
メール：masaikaw●microsoft.com
（●を@に置き換えて）
電話：09025411718

756 ：ナイコンさん：2016/05/21(土) 11:18:26.21 .net

リトルエンディアンの利点なんて多倍長の加減算をより速く実行出来ること位だろ。
下位桁から読み込むから、「読み込み即加減算可能」っていうbusのbit幅やALUのbit幅が
狭い頃の遺物だ。

その点ビッグエンディアンの利点は上位桁から比較できるので「より速く大小判定できる
可能性がある」って位だな。
ビッグエンディアンでも下位桁から上位桁に向けて多倍長データを読めるようにbusコント
ローラを作れば同じことが出来るけど、そんな対応をしたMPUは寡聞にして知らないな。

757 ：ナイコンさん：2016/05/21(土) 11:22:53.65 .net

>>751
> アドレス「の上位」部分を受信した時点で
なら変わるんじゃないかな？
そういうプロトコルや実装があるのかは知らんがｗ

758 ：ナイコンさん：2016/05/21(土) 11:29:59.30 .net

>>757
一般的じゃないけどATMの中継機なんかがそうだったはず。
アドレスの割り振りがエリアID、装置IDみたいになってて他のエリア宛だとエリアID受信したらそっちに飛ばすしかけになってる。
固定長データだから出来る芸当やね。

もう20年近く前にNTTの仕事でやったのに記憶の彼方だわ。
「一般教養だ」って言われてそれなりに覚えさせられたはずなんだがなー・・・

759 ：ナイコンさん：2016/05/21(土) 11:50:57.46 .net

>>756
とてもわかり易くて合理的だ、サンクス
技術的にはこんなもんでしょ
あとは好み

俺は機械じゃなくて人間だからビッグエンディアン(上位桁から下位桁に向かって意識するやり方)のほうが扱いやすい

760 ：ナイコンさん：2016/05/21(土) 15:39:18.37 .net

このスレ的には古すぎてスレチかもしらんけど、こんなのはどうよ
Z80にて
　　LD HL,3132H
　　LD (TEXT_VRAM_ADDR),HL　;懐かしきテキストV-RAM上のどこか

これを実行したら画面上には "21" って表示じゃないか？
リトルエンディアンってスリリング

761 ：ナイコンさん：2016/05/21(土) 16:40:58.25 .net

>>760
VRAMがビッグエンディアンで並んでたらどうなる？
それに、ビッグエンディアンで書いたら

762 ：ナイコンさん：2016/05/21(土) 18:42:38.16 .net

これは楽しいなw
プレーン方式のグラフィックV-RAMで、14dot離れた2個のdotに点を打とうとすると…
　　or word ptr[si],8001h　　; si:V-RAM上のどこか

あれ？

763 ：ナイコンさん：2016/05/21(土) 20:06:39.61 .net

>>762
とりあえず
　or byte ptr[si],80h ; si:V-RAM上のどこか
　or byte ptr[si+1],01h
にして、その後最適化したときに、
;　or byte ptr[si],80h ; si:V-RAM上のどこか
;　or byte ptr[si+1],01h
　or word ptr[si],0180h
として置くかな？ｗ

シフトだと
　shr word ptr[si],1 ; si:V-RAM上のどこか
じゃダメで
　shr byte ptr[si],1 ; si:V-RAM上のどこか
　ror byte ptr[si+1],1
にしないと上手くいかない。

グラフィックV-RAMとビッグエンディアンの親和性はMacintoshが出た頃に良く言われてた気がする。

764 ：ナイコンさん：2016/05/21(土) 22:09:45.22 .net

何を問題にしてるのかさっぱり分からん。

765 ：ナイコンさん：2016/05/21(土) 22:18:10.97 .net

？を多用してるから本人も分かってない。

766 ：ナイコンさん：2016/05/21(土) 22:18:47.84 .net

個人的にはcharだろうがshortだろうがlongだろうが同じアドレスから読むリトルがすっきりしていて良いと考える。
long型からキャストした結果を取り出すとき、charだと＋3、shortだと＋２とアドレスに補正かける必要があるビッグエンディアンはムダな手間が増えてる間抜けな設計。

VRAMへのアクセスは「CPUに内蔵されてない」から、取り上げるべきではないと思う。
VRAMが許されたらどんなデバイスもOKになってしまうから。

767 ：ナイコンさん：2016/05/21(土) 22:26:53.12 .net

WORDアクセス禁止のVRAMにWORDアクセスする方が悪い。
VRAMにはきちんとBYTEアクセスすべき。

768 ：ナイコンさん：2016/05/21(土) 22:45:03.92 .net

別にVRAMそのものじゃなくても、
モノクロビットマップデータとしても良く使われるデータ形式だろ。

769 ：ナイコンさん：2016/05/21(土) 23:25:33.78 .net

>>766
>「CPUに内蔵されてない」から
よく分らん理屈だw

770 ：ナイコンさん：2016/05/22(日) 00:49:43.92 .net

> WORDアクセス禁止のVRAMにWORDアクセスする方が悪い。
> VRAMにはきちんとBYTEアクセスすべき。

こんなこと言ってる奴がポインタ型のキャストがどうこう言うんだから不思議。

771 ：ナイコンさん：2016/05/22(日) 03:45:49.44 .net

そもそもアセンブラレベルのプログラミングじゃキャストとかしない（しないように作る）
キャストするのはC言語とかだけど、その場合はコンパイラがが処理するから面倒は無い
さらにコンパイラはビットシフトしたり毎回アドレスを加算修正したりする効率の悪いコードも出力しないから性能問題も無い

対してビットイメージのようなデータは言語によらずプログラマが意識して操作するものだからエンディアンによっては注意が必要になる

772 ：ナイコンさん：2016/05/22(日) 04:09:10.82 .net

unsigned long *p = どっかのアドレス; // longは32bit
unsigned char d;

d = (unsigned char)*p;
こうすればエンディアン気にしなくてもいいのに

d = *(unsigned char*)p; // リトルエンディアン
d = *((unsigned char*)p + 3); // ビッグエンディアン
わざわざこう書き分けないよな

773 ：ナイコンさん：2016/05/22(日) 04:18:30.29 .net

値渡しで済むなら値渡しでいいだろうが、参照渡しをしたい場合の解決にはなっていない。
処理によってはとんでもない処理コストを産む。

774 ：ナイコンさん：2016/05/22(日) 08:16:46.22 .net

>>773
> 処理によってはとんでもない処理コストを産む。
具体的には？

775 ：ナイコンさん：2016/05/22(日) 08:18:36.60 .net

>>774
773の頭中nopの無限ループ。

776 ：ナイコンさん：2016/05/22(日) 08:23:20.17 .net

>>774
詳細はWEBで。

777 ：ナイコンさん：2016/05/22(日) 08:25:56.64 .net

>>774
参照渡しが必要なときすべて。

778 ：ナイコンさん：2016/05/22(日) 08:36:02.11 .net

>>774
詳細は第三者プログラマに検証を依頼しております。
後日、検証結果をお知らせしますので、それまでお待ち下さい。

779 ：ナイコンさん：2016/05/22(日) 08:39:51.27 .net

>>774
お見積もりするにはお金がかかりますがよろしいでしょうか。

780 ：ナイコンさん：2016/05/22(日) 08:43:37.01 .net

>>779
見積もりだけでカネ取るんかい。アコギやなぁ〜w

781 ：ナイコンさん：2016/05/22(日) 08:44:34.54 .net

馬鹿の相手はキリがないからな。IT業界の常識。

782 ：ナイコンさん：2016/05/22(日) 09:24:28.58 .net

>>780
じゃあおまえが調べてくれ。午前中までな。遅れたら遅延金な。

783 ：ナイコンさん：2016/05/22(日) 09:31:46.91 .net

別の型として参照渡しというのは、
void func(char * p)
{ *p++; }

void main(void)
{ long l = 1;
func((char*)&l);
}
ということだろう。
リトルならlの値1が正しく渡せ、lの値も2になるけど
ビッグの場合はlの値1が0として渡ってしまい、lの値も0x01000001になってしまう。

まぁ、言いたいことはわかるが、
実際こんなコードが必要なケースなんてないよなｗ

784 ：ナイコンさん：2016/05/22(日) 09:33:45.73 .net

無駄な議論だね。68Kはもうないのだから。

785 ：ナイコンさん：2016/05/22(日) 10:51:56.51 .net

>>762
直接V-RAM上のデータをいじろうとせず、レジスタに読んで xchg でまずバイト位置を
補正しろ。演算が終わったら書き込む前にもう一度 xchg だ。

32bit/64bit では xchg の代わりに bswap だ。
インテルもリトルエンディアンのまずさには気が付いている、安心しろ。

786 ：ナイコンさん：2016/05/22(日) 12:26:01.98 .net

それじゃ無駄が多いから0180hで

787 ：ナイコンさん：2016/05/22(日) 12:37:36.22 .net

>>762
例えば9801の0xA800から96KB割り当てられたV-RAMみたいなイメージなのだろう。
80byte 640bitで640ドット1ラインとか。しかし、128Kmacでさえビデオ画面はQDで
仮想化され座標系で位置指定するAPIで描画していたわけで、古代仕様・錯誤甚だしい。

ビットがドットに対応するビットマップデータとかVRAMとか、脳内カビ詰まりまくりのまんまで
よく今まで生きて来られたなって感じw

788 ：ナイコンさん：2016/05/22(日) 12:48:40.09 .net

>>783
そうだよなw
仮にそのコードを使った場合、元のlong値の上位ビットが0以外の値だとトンデモナイ事になるわけで
longなりcharなりに統一しておくべきだよ

789 ：ナイコンさん：2016/05/22(日) 13:25:26.98 .net

ビットマップVRAMはCPUのエンディアンがどうであれ、バイト単位で81h書いたら●○○○-○○○●を、ワード単位で8001h書いたら●○○○-(○×8)-○○○●をとなるように作るのが正道だろうに、なんでそうしなかったんだ？

790 ：ナイコンさん：2016/05/22(日) 13:38:26.90 .net

>>789
ワード単位で8001hを書くとメモリ上では01h,80hで、
表示は ●○○○○○○○ ○○○○○○○● になるけど、

バイト単位で01h,80hと続けて書くとメモリ上では同じ01h,80hだが、
表示は ○○○○○○○● ●○○○○○○○ になるのか？

ちょっと何を言ってるのかわからないんだが…

791 ：ナイコンさん：2016/05/22(日) 13:56:15.06 .net

＞＞７９０
あー・・・酔っ払って書いてるからちょっとヘンだわ。
言いたいのは「何でCPUのエンディアンに合わせて、ワードやロングワードのアクセスのときにバイト位置を入れ替える回路にしなかったの？」ってこと。

792 ：ナイコンさん：2016/05/22(日) 16:54:27.27 .net

>>791
ワード境界やロングワード境界にアラインしたアクセスならデータバスへの接続を入れ替える
だけなので簡単。
問題はミスアラインしたアクセスへの対応。外部から検出できるなら、アドレスエラーなりバス
エラーを返して終わりにしたい。

793 ：ナイコンさん：2016/05/22(日) 17:39:32.49 .net

VRAMにワード単位で8001hを書き込んだ後、同じアドレスをバイト単位で読み込むと
80h,01hと読み出せる、つまりVRAMだけ見かけ上ビッグエンディアンになるのか。

それだとメインメモリ上にあるビットマップ
●○○○○○○○ ○○○○○○○●
をワード単位で読んで(0180h)それをその仕組みのついたVRAMに書き込むと
○○○○○○○● ●○○○○○○○
として書き込まれちゃうよね？
役に立たないどころかむしろ邪魔な気がするんだけど…

794 ：ナイコンさん：2016/05/22(日) 19:31:19.53 .net

>>793
それって、今時のWinows10マシンとかMacBookとかで検証できるのか？

795 ：ナイコンさん：2016/05/22(日) 21:58:01.26 .net

Winows10マシンやMacBookを標準のOSで使わなきゃいけない理由もないし
なんとでもできるだろ

796 ：ナイコンさん：2016/05/22(日) 21:58:37.24 .net

445 ：ナイコンさん：2012/07/12(木) 07:13:57.20
http://ameblo.jp/akatenjpn/entry-11204577834.html
怪しすぎる「ゲーム保存協会」。

噂ではＤ４エンタープライズに絶縁された「アジト」は、Ｗｉｉでバーチャルコンソールを
始めた任天堂に「コンパイルのソフトの権利者は我々です！」と売り込もうとした事があり、
もちろん任天堂はそんな詐欺に引っかからなかったという事があったようです。
　それに懲りずにこんどは「ＨＡＬ研のソフトをただでよこせ！」と言いに行ったというのですから、
そしていわゆる逆ギレしているのですから、日下さんは神様のように偉い人か、人格障害かのどちらかだと思います。

446 ：ナイコンさん：2012/07/12(木) 07:19:03.41
MSX研究所
http://home.a02.itscom.net/msx_lab/

https://twitter.com/yoshimatsuTUQ
MSX研究所長 ‏@yoshimatsuTUQ
職場で鼻毛が出たままの人が複数いるのだが、どうして気がつかないのだろう。鏡とか見ないのだろうか。指摘しても無駄だろうから誰も何も言わず、今日も元気にはみ出している。

797 ：ナイコンさん：2016/05/22(日) 22:04:43.22 .net

モノクロ2値の画像形式とかありそうで無いよな

798 ：ナイコンさん：2016/05/22(日) 22:05:12.88 .net

>>795
>なんとでもできるだろ

じゃあ、具体的な機器環境を示した上でコード書いてみろよ？

799 ：ナイコンさん：2016/05/22(日) 22:06:57.61 .net

>>797
たくさんあるだろ
ttps://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88#.E8.A9.B3.E7.B4.B0.E3.81.AA.E6.AF.94.E8.BC.83

800 ：ナイコンさん：2016/05/22(日) 22:07:38.19 .net

>>798
> じゃあ、具体的な機器環境を示した上でコード書いてみろよ？

なんで??

801 ：ナイコンさん：2016/05/22(日) 22:07:46.48 .net

>>797
9801がモノクロビットプレーン。
3枚重ねで8色。4枚重ねで16色というマヌケなハードウェアw

802 ：ナイコンさん：2016/05/22(日) 22:11:20.45 .net

>>799
ファイルフォーマットの名称を羅列されてもなw

803 ：ナイコンさん：2016/05/22(日) 22:15:13.26 .net

>>802
ひょうのよみかたもおしえてもらわないとわからないんでちゅか？

804 ：ナイコンさん：2016/05/22(日) 22:17:08.48 .net

>>797
https://en.wikipedia.org/wiki/Netpbm_format
https://en.wikipedia.org/wiki/X_BitMap

805 ：ナイコンさん：2016/05/22(日) 22:23:52.35 .net

>>803
カラーデブス・カラー表現の仕組み、ファイルフォーマットは一覧表からじゃわからんね。
だいたい多色サポートな画像ファイルが1バイト8ビットなビットマップなど採用などしトランプ。

806 ：ナイコンさん：2016/05/22(日) 22:30:07.38 .net

>だいたい多色サポートな画像ファイルが1バイト8ビットなビットマップなど採用などしトランプ。

マジか
https://ja.wikipedia.org/wiki/Windows_bitmap

807 ：ナイコンさん：2016/05/22(日) 22:30:59.23 .net

>>804
どっちもASCIIコードファイルじゃんかw

808 ：ナイコンさん：2016/05/22(日) 22:36:29.94 .net

>>806
BMPファイルw

809 ：ナイコンさん：2016/05/22(日) 22:39:38.65 .net

「モノクロ2値の画像形式とかありそうで無いよな」

↑を読んで「1バイト8ビット(8ピクセル)バイナリ形式」を読み取れる人は
そうはいないだろうな。