facebook twitter hatena line google mixi email
★お気に入り追加


■ このスレッドは過去ログ倉庫に格納されています

  • 1
  •  
  • 2010/04/21(水) 12:42:23
mov dx,offset msg
mov ah,9
int 21h
mov ax,4c00h
int 21h

msg db '懐かしのDOS時代のプログラミングについて語ろうぜ',0dh,0ah,'$'

ここまで見た
  • 737
  •  
  • 2014/02/15(土) 05:03:36.87
>>736
何言ってんの??

ここまで見た
  • 738
  •  
  • 2014/02/15(土) 10:49:42.54
SP「俺の名前を言ってみろ」

ここまで見た
スペシャルスタックポインタ

ここまで見た
  • 740
  •  
  • 2014/02/15(土) 17:45:09.43
すっぽん

ここまで見た
  • 741
  •  
  • 2014/02/15(土) 21:39:33.80
DOS用のForthおしえて

ここまで見た
  • 742
  •  
  • 2014/02/15(土) 22:09:41.69
http://www.forth.org/compilers.html

ここまで見た
  • 743
  •  
  • 2014/02/16(日) 23:18:39.26
Delphi始めたんですけど、複雑でわからないんで、Quickbasicに戻りたいんですけど、
もうないんですかねぇ。

ここまで見た
  • 744
  •  
  • 2014/02/17(月) 00:08:16.64
Win32で動く互換品でよければ、
QB64(32bit版もある)でいいんとちゃう

ここまで見た
  • 745
  •  
  • 2014/02/18(火) 20:01:20.24
>>744
ありがとうございます。
便利なものがあるんですねー。
>>744さんと制作者さんに感謝^^

ここまで見た
  • 746
  •  
  • 2014/02/21(金) 13:00:41.98
Cコンパイラを初めて使ったとき、その吐き出したコードの大きさに驚いた。
Hello, worldが2kBくらいになって出てきたから。
アセンブラなら
 mov dx,label
 mov ah,9
 int 21h
 ret
label:
 db 'hello, world.',13,10,'$'
たった24バイトで作れるのに。
当時まだFDD2台だったが、こりゃHDDが必要だなと感じたよ。

ここまで見た
  • 747
  •  
  • 2014/02/21(金) 22:00:15.53
スモールモデル: コード64kB データ64kB

(8bit環境から見ると)全然スモールじゃないやん・・・

ここまで見た
  • 748
  •  
  • 2014/02/21(金) 22:12:43.44
8080でもコードとデータでそれぞれ64KBのメモリ空間持てるし大したことではない

ここまで見た
>>747
お前タイニーモデルをしらんのか?

ここまで見た
>>748
8080 はコード・データ他スタックもみな共用での 64KB だ

ここまで見た
  • 751
  •  
  • 2014/02/22(土) 04:37:55.46
>>750
外から区別できるの知らんのねw

ここまで見た
>>751
8080にMMUのようなものは内蔵されていないからね
IOポート番号を16bit とれるようになったは Z80 からだね

ここまで見た
  • 753
  •  
  • 2014/02/22(土) 11:09:45.41
スモールにしろタイニーにしろ
それを超える範囲のメモリにアクセス出来ない訳じゃない
単にセグメントディスクリプタのデフォを適当に初期化してくれるだけ

ここまで見た
  • 754
  •  
  • 2014/02/22(土) 11:38:39.71
>>752
SYNC信号がHIGHのタイミングでデータバスを見れば、コード/データ等外部で判別可能。
http://www.classiccmp.org/dunfield/r/8080.pdf
http://en.wikipedia.org/wiki/Intel_8080

ここまで見た
>>754
それでどうやって >>748 のコードセグメントとデータセグメントをそれぞれ別に64KB確保できるようになるのか?

ここまで見た
  • 756
  •  
  • 2014/02/22(土) 15:28:13.23
スタックセグメントもデータセグメントとは別に64KB確保できるな

ここまで見た
  • 757
  •  
  • 2014/02/22(土) 16:03:56.04
8080にセグメントの概念などない

ここまで見た
  • 758
  •  
  • 2014/02/22(土) 16:12:48.73
アクセスの種別によってメモリ空間を分けることは可能だし、それをセグメントと呼んでも差し支えない。

ここまで見た
  • 759
  •  
  • 2014/02/22(土) 16:15:27.07
後期のZ80 BASICマシンのメモリレイアウトなんて
ほとんど曲芸状態だったよな

ここまで見た
  • 760
  •  
  • 2014/02/22(土) 16:19:07.68
いや全然

ここまで見た
  • 761
  •  
  • 2014/02/22(土) 16:27:34.62
>>758
理屈じゃなく過去の具体的な実装事例は?

ここまで見た
  • 762
  •  
  • 2014/02/22(土) 16:32:17.51
>過去の具体的な実装事例は?

そんな話誰もしてないだろ

ここまで見た
  • 763
  •  
  • 2014/02/22(土) 16:57:12.73
Z80で64kbite BASIC-ROM、64kbite RAM、64kbite VRAMなパソコンだと
コードとデータの分離や切り替えが効かないとはじまらんだろ

ここまで見た
  • 764
  •  
  • 2014/02/22(土) 16:57:14.65
データバスをチェックとかわけわからんがな、all 0 だったらどうするつもり?

>アクセスの種別によってメモリ空間を分けることは可能だし、
おいおい、データがきてからアドレスバスを変えるのかよ?なんのためにあんだけのマージンとってんだ?

ここまで見た
  • 765
  •  
  • 2014/02/22(土) 16:59:18.33
>データバスをチェックとかわけわからんがな、all 0 だったらどうするつもり?

>おいおい、データがきてからアドレスバスを変えるのかよ?なんのためにあんだけのマージンとってんだ?

なんだ、タイミングチャートも見れない素人かw

ここまで見た
  • 766
  •  
  • 2014/02/22(土) 17:03:51.14
>>763
>Z80で64kbite BASIC-ROM、64kbite RAM、64kbite VRAMなパソコンだと
>コードとデータの分離や切り替えが効かないとはじまらんだろ

バンク切り替えやI/OにVRAM置いたり色々実装はあったが、コードとデータの分離をやった例って聞いたことないわ。
Z80は命令も多いし外部回路でM1サイクル監視するにしてもコードの4バイト目まで判定するのは骨だろう。

ここまで見た
  • 767
  •  
  • 2014/02/22(土) 19:02:02.20
コードとデータが分離できてりゃ
バッファオーバーフロー脆弱性なんか
起こらないだろうね。

そんなもんあんの?

ここまで見た
  • 768
  •  
  • 2014/02/22(土) 19:10:11.64
>>767
意味知らないで「バッファオーバーフロー」とかって恥ずかしくない?

ここまで見た
  • 769
  •  
  • 2014/02/22(土) 19:10:55.40
石頭ハード屋の妄想はつまらんわ

ここまで見た
  • 770
  •  
  • 2014/02/22(土) 19:14:02.65
>>768
意味なら調べればよかろう?

http://www.ipa.go.jp/security/awareness/vendor/programmingv1/b06_01.html
> バッファオーバーラン(注1)
> バッファオーバーラン問題は,C 言語やC++ で書かれたパッケージソフトウェアが
> 抱えるセキュリティ脆弱性の中で最も頻繁に報告されるものの一つである。
>  
> バッファオーバーランとは元々,コンピュータのメモリ上の領域(バッファ)よりも
> 大きなデータが渡されているのにプログラムがそれを見逃して領域あふれ(オーバーラン)が
> 起きてしまうことを指す。ところが,こうした欠陥を《うまく》悪用すると,
> そのプログラムのメモリ上に任意のマシン語プログラムを送り込み実行させることが可能になる場合がある。
> 標的プログラムが高い権限で動作するものだった場合,その権限を乗っ取って対象コンピュータを意のままに操ることができてしまう。
>  
> (注1・「バッファオーバーフロー」とも言う。本稿では「停まるべき箇所で停止できなかった」
> というニュアンスが強い「オーバーラン」の語を主に用いている。)

それで君はなにがいいたいのだ?

ここまで見た
  • 771
  •  
  • 2014/02/22(土) 19:21:16.00
>>770
>> バッファオーバーランとは元々,コンピュータのメモリ上の領域(バッファ)よりも
>> 大きなデータが渡されているのにプログラムがそれを見逃して領域あふれ(オーバーラン)が
>> 起きてしまうことを指す。

自分で引用してて↑の内容がコードとデータの分離とは関係ないって理解できないのかw

ここまで見た
  • 772
  •  
  • 2014/02/22(土) 19:30:31.26
馬鹿には無理

ここまで見た
  • 773
  •  
  • 2014/02/22(土) 19:58:39.00
「ハードに比べたらプログラミングなんて子供の遊びレベル」と
うそぶく老害は昔からどこにでもいるが、こいつもその一人だろう。
生半可な断片知識で専門外の領域にしゃしゃり出てきて大恥かくのも毎度のこと。

ここまで見た
  • 774
  •  
  • 2014/02/22(土) 20:03:46.62
>「ハードに比べたらプログラミングなんて子供の遊びレベル」と
>うそぶく老害は昔からどこにでもいるが、こいつもその一人だろう。

よほどのコンプレックスがあるらしい

ここまで見た
  • 775
  •  
  • 2014/02/22(土) 20:08:10.35
普段誰からも相手にされず、寂しさと承認欲求のあまり
ここに来てみたんだろうが… 哀れなもんだなw

ここまで見た
  • 776
  •  
  • 2014/02/22(土) 20:15:01.69
>>774
で、773の最後の行は否定しないのな(笑

ここまで見た
  • 777
  •  
  • 2014/02/22(土) 20:31:09.11
>>773
よくわからんのだけど「生半可な断片知識で専門外の領域にしゃしゃり出てきて大恥」って
>>767=>>770 のこと? どうみてもハードもソフトも分かってない風だけど。

ここまで見た
  • 778
  •  
  • 2014/02/22(土) 20:47:00.10
>>777
必ずしも 専門=エキスパート じゃないけどな
どんなに落ちこぼれであっても、ある分野で飯食ってりゃ一応専門家

ここまで見た
>>767
6809

スタックを分離するだけでわりと十分

ここまで見た
  • 780
  •  
  • 2014/02/22(土) 22:24:07.92
バッファオーバーフローとスタックは直接関係ないので間違い

ここまで見た
  • 781
  •  
  • 2014/02/22(土) 22:49:42.64
>>777
いんや、お前のこと。

ここまで見た
  • 782
  •  
  • 2014/02/22(土) 22:52:39.91
理屈も語れない馬鹿がなんか言ってるなw

ここまで見た
  • 783
  •  
  • 2014/02/22(土) 22:53:33.46
>>771
コードとデータの分離は関係あるよ。

データ部分の実行を制限するのがNXビット
もちろんこれは比較的最近作られたもの

http://ja.wikipedia.org/wiki/NX%E3%83%93%E3%83%83%E3%83%88
NXビットは、端的に言えば「データの誤実行」を防ぐために用いられる。
そのしくみは、メモリをコード(プロセッサ命令)領域とデータ領域とに分離し、
データを配置したメモリ領域にあらかじめ特別な印(属性)を付与することで、
この領域のデータを実行しないようにする(実行を試みた際に例外=エラーを発行する)ものである。

典型的には、バッファオーバーラン攻撃(後述)等に代表される、ヒープやスタック領域等に
置かれたデータを破壊ないしは書き換えて任意のコードを挿入し実行を誘う攻撃を、
オペレーティングシステムとCPUの協調により保護するために用いられる機能である。
その機能自体は、汎用機やワークステーション等の分野では既に特に目新しいものではなかったが、
パーソナルコンピュータ用に最も普及したIA-32/AMD64アーキテクチャにおける実装は比較的最近の出来事であり、
最初に実装したAMD64系列が搭載したものを"NXbit"と呼称したため、一般にはこの名称が普及した。

ノイマン型アーキテクチャのコンピュータでは、プログラムをメモリ上にデータとして読み込み、逐次実行する。
メモリを読み取った際それがデータであるかプログラムであるのかを、単にメモリ上のデータのみをもって判断することは、
ノイマン型では本質的に不可能である。バッファオーバーラン(バッファーオーバーフロー)等と呼ばれる攻撃は、
ノイマン型コンピュータのこのような性質を悪用して行われる。

ここまで見た
  • 784
  •  
  • 2014/02/22(土) 23:05:12.78
>>783
バッファオーバーラン攻撃って目的が任意のコード実行とは限らないんでトンチンカンなこと言ってますよ

ここまで見た
  • 785
  •  
  • 2014/02/22(土) 23:08:23.73
>>784
え? だからなに?
バッファオーバーラン攻撃の目的が任意のコード実行だ。とは
ひとことも言ってないけど? そんな話してないけど?

コードとデータの分離の話。

コードとデータの分離なんてされてないのが普通。

ここまで見た
  • 786
  •  
  • 2014/02/22(土) 23:18:41.88
>コードとデータの分離なんてされてないのが普通。

ハーバードアーキテクチャも知らない人か…

ここまで見た
  • 787
  •  
  • 2014/02/22(土) 23:21:16.63
>>785
> え? だからなに?
> バッファオーバーラン攻撃の目的が任意のコード実行だ。とは
> ひとことも言ってないけど? そんな話してないけど?

↓を引用しててよく言うww

> 典型的には、バッファオーバーラン攻撃(後述)等に代表される、ヒープやスタック領域等に
> 置かれたデータを破壊ないしは書き換えて任意のコードを挿入し実行を誘う攻撃を、
> オペレーティングシステムとCPUの協調により保護するために用いられる機能である。

ここまで見た
  • 788
  •  
  • 2014/02/22(土) 23:30:52.76
>>786
今のパソコンはハーバードアーキテクチャではなくて
ノイマン型アーキテクチャですよ。

なにみんなと違うコンピュータの話してるのさ?
お前の話はみんなと違うコンピュータの話だったんだな。

通りでずれてるはずだ。

フリック回転寿司
フリックゾンビ
ここまで見た

★お気に入り追加

このページを共有する
facebook twitter hatena line google mixi email