[Jill Leukhardt:] We were not cognizant of the importance of software that was being developed for the PC and its user base, so what is obvious today in terms of the installed base of software and the vast importance of that compatibility was not at all obvious when we were entering into the definition phase for the 386.
In terms of the competitive environment, the Motorola 68000 was a superior machine, and we knew it and felt it very strongly. We perceived that we were going to be later than the 68020, the Motorola 32-bit product that we would be later to market with the 386 and so we felt that very strongly and that created a real sense of urgency in terms of what we were trying to do.
Third, we were stuck with the 8086 approach to segmentation that was wildly reviled; everybody hated 64K-byte segments. They limited the size of data structures and that was perceived to be and was actually a limitation in certain applications. Programmers in particular and compiler writers and others just saw that as a huge limitation. Jim you want to say something?
[Jim Slager:] Oh yes it’s just humorous when you look back…that we thought it was so important to have a segment-based memory management scheme because of the Zilog MMU and it was defined into the 286 and we just thought it’d be the greatest thing in the world but customers just didn’t agree, I don’t know what was wrong with them <laughter.>.
司会 [Jim Jarrett:] So it’s early 1982 you’ve got the 286 out; there’s; nobody particularly wild about it, but it’s moving along and now a new effort is beginning to develop: a follow on to the 286, and that’s where you all come together. What was the environment within Intel at that point and the thinking about this new chip?
では1982年の初めに286を世に出して、誰も特に熱狂はしなかったがそれは続き 今度は286の後継機を新たに開発するために皆さんが集められたわけですね。その時点 で新チップに関するインテル内部の方針や環境(雰囲気?)はどうだったのでしょう? (p5) [Gene Hill:] Well actually that chip started as a non-chip; the 286 was so unsuccessful, Bill Gates called it “Brain Dead”. IBM said there could not be a follow-on; it was a dead-end architecture.
[Jarrett:] If you couldn’t do a follow-on to the 286, what was the next processor that Intel was thinking of bringing out?
286の後継が不可能とすると、次期プロセッサとしてインテルは何を考えていたのでしょうか?
[Crawford:] This was all in the shadow of the 432 microprocessor development at the time. The 432 was a very ambitious project that Intel was very firmly committed to and unfortunately it was also late and had slipped pretty significantly; so we had a number of gap fillers that were thrown into the breach. That was a little before my time, but my understanding is the 8086 microprocessor was the first of those gap fillers, followed by the 8088, the 186 and the 286. That’s another key piece of information here: the 432 project was really supposed to be our big thrust in the microprocessor market and these other efforts were really more or less gap fillers.
[Prak:] There was a variety of proposals to come up with a new architecture because there were a lot of people who realized the 432 was fatally flawed. So the project I joined originally was code-named the P4 and it was a whole new architecture that was very VAX-like. It was developed by Glen Meyers and the people in Oregon who had been responsible for the 432 wanted to try again. A number of them realized there were problems, so they wanted to do it over basically. So they had a proposal and as Gene indicated the 386, 32 bit follow-on was kind of the step child already in that discussion.
(p6) [Jarrett:] So this 386 effort was launched and I guess the first thing we need to talk about is the definition of it. I guess Jill and John you were quite involved in that process; tell us about it.
[John Crawford:] So the definition effort started-- I was there a little bit before Jill, just a few months before and there actually were two architects on the 386. There was the effort that Gene talked about earlier that Bob Childs had pulled together. It was a proposal for a 32-bit extension of the 286 and Glen Meyers had asked me to step in and do one, and so we had these two sketches of what an extension might be. So we had kind of the battle of the architectures going on a little bit.
設計が始まりました、私はJillよりほんの少し、数ヶ月前からですが、実は386には二人の 設計者がいました。先ほどGeneの話にあった取組みは Bob Childs が主導していたのです。 それは286を32bitに拡張する提案で、Glen Meyersは私にその一つに入るように指示し 拡張がどうあるべきかを、二つのスケッチ(方針)で社内競争させるようなものでした。
George Alexy was the Marketing Manager and he took Bob Childs and me out to seven selected customers to bounce both sketches off of the potential customers and get feedback from them.
[Jarrett:] So what were the key differences between the two approaches: yours and Childs? あなたのとChildsのと二つのアプローチのおもな違いは何だったのでしょう?
[Crawford:] My proposal was a simpler upgrade and I think kind of the essence of it was to focus on the key issues, which were to extend the address space to 32 bits and in particular provide a flat addressing of 32 bits. That was a key failure or lack in the 286 that I think was mentioned earlier.
(p7) Second thing was to make it a full 32 bit machine so have some way of giving it a full 32 bit instruction set. The other thing that we wanted to fix was to increase the number of registers. The proposal I put forward was a more minimal extension and admittedly it fixed two of the three issues. It provided the flat 32 bit addressing. It supplied a full 32 bit instruction set. It did not change the number of registers. The proposal and the instruction set looked-- the instruction setting coding was very similar to the 8086. So the instruction decode piece would have been a small change or a much smaller change.
Child’s proposal on the other hand tried to address all three and in doing so he ended up with a much more complicated instruction encoding strategy. In particular the 32 bit instruction set was quite different from the 16 bit instruction encoding. It did provide the opportunity though to increase the number of registers, which addressed the third point. Today I can’t remember how well it did on the first two but he did have the distinguishing factor that it increased the number of registers.
[Jarrett:] The customers gave you input and chose your approach -- correct? 顧客の意見はあなたのアプローチを選んだ… ということで正しいですか?
[Crawford:] Well I think we got mixed feedback from the customers. There were some customers that didn’t care at all about 8086 compatibility. We wanted to see a broad range of customers, some of whom weren’t even using our products, so clearly they wouldn’t care much about the compatibility. Others were quite concerned about it, but I think overall the feedback was compatibility would be nice to have but not critical, and that is kind of curious looking backwards. On the other hand, our field application engineers gave us very strong feedback that we had to run the old software, and that would be critical for success of the project and also critical for continued success of the 286 and the other products.
[Jarrett:] Was this was PC software they were concerned about? 彼らが懸念していたのは、PCソフトウェアの互換性だったのでしょうか?
[Crawford:] Oh no, not at the time, I think it wasn’t that long since August of 1981 with the big IBM PC introduction. It seemed that the PC was an interesting design but not one viewed as really the key thing to win and to do well on. Instead there was still a broad range of designs from the terminals to kind of little minicomputers to the personal computers which were just emerging.
[Jarrett:] How about the work stations? At this point was that considered to be a market to focus on?
ワークステーションはどうでしょう? これについて、市場の焦点として考慮しましたか?
[Leukhardt:] Well we thought that was a key market segment for the 386. It was not a market segment where the 286 was doing well at all; it was a market segment where the 68000 was cleaning up principally because the 286 was not viewed as a machine that ran Unix well and the 68000 was viewed as a natural Unix machine. So when we were working on the 386 definition we wanted it to have as one of its attributes being able to run Unix well. So that’s one of the things that influenced us in terms of wanting to have a way to run the 386 as a flat 32-bit machine, and that’s one of the things that led to all the angst in the definition process about compatibility versus a flat 32bit machine and how they would coexist.
[Jarrett:] So that shapes up as a key challenge architecturally; how did you address that? アーキテクチャ的に挑戦すべき鍵となる点が形作られたわけですが、どう取扱いましたか?
(p8) [Crawford:] In fact that was one of the most difficult architectural issues that I had to wrestle with: how to keep that compatibility with the segmentation yet provide this thing and I know we went through endless iterations and had a lot of advice from many people. In the end the thing that worked was inventing a fictional address space in between the programmer’s virtual address space and the physical address that you go to memory with; in fact we had to invent a new name for it, so we called it the “linear address space” We kept the segments but we provided the ability to have a segment that was four gigabytes in size and that let the workstation guys and the Unix people address this four gigabyte flat address space basically by setting up one segment and having all of their programming objects within that one segment.
[Slager:] Of course there’s controversy about all of this and, you know, it’s incredible and one thing that I remember well is that the architect of the 8086, one of the two architects, Steve Morris, who started the whole X86 phenomenon… he was bitterly opposed to the segmentation model that was installed in the 286. When the 386 turn came he was very active-- he was still at Intel in software somewhere-- and he was very much opposed to the segmentation model because of the two-part pointers. In fact he called it software poison.
This was the environment that John had to work in and he did come up with a brilliant solution. We ultimately ended up with the best of all worlds: we had the compatability, but that whole segmentation model which was pretty much generally hated could just move over to the side and not interfere with the software. It still had to be there, we had to design it in and test it and that was pretty bad, but it could get out of the way and not prevent the success of the 386.
[Leukhardt:] Now in some ways we’re getting ahead of ourselves because we got to the solution that included segmentation plus a flat address space, sort of the “have it your way” approach after we made the decision that we had to build a fully compatible machine that is an object code compatible 386, and that took a long time to decide. In retrospect that seems like a completely obvious decision but we wrestled with that decision for months and it was a tough decision-making process.
[Jarrett:] So John, you came up with this new approach that would accommodate both segmentation and paging. Was there any kind of a performance price that you paid as a result of this?
[Crawford:] That’s an interesting question; in fact it was obviously a big concern because we were putting in two translation steps. Of course it’s a critical path on any computer, and that was a big concern all through the internals of the chip and even the BUS definition that was a careful concern. But the advantage was, I think it was mentioned before, we got the best of both worlds: we had segments for compatibility and paging for a flat address base; that was pretty much everybody.
[Jarrett:] Now internally, did everybody buy into this immediately or was there some debate on this approach?
社内的には全員がすぐに賛成したのですか、それともこの方法に何か議論がありましたか?
[Crawford:] Well, I think that came at some point in 1982, but before that there were many proposals, obviously which didn’t survive, that didn’t solve the problem as completely. At some point there was a decision taken to go with my architecture as opposed to the Bob Childs architecture. As I remember, a key part of that was involved the software compatibility question and how efficiently we needed to run old software, and whether there would be a mode bit and basically have two machines in one or something more tightly integrated.
ええ、これは1982年のどこかだと思いますが、それ以前は多くの提案がありました。 明らかにどれも生き残りませんでした。完全には問題を解決できなかったからです。 ある時点で Bob Childsのアーキテクチャでなく、私の案で行く決定がなされました。 私の記憶では鍵となる要素には、互換性の問題や古いソフトをどの程度効率よく動かす 必要があるか、モード・ビットを使って基本的に二種のマシンを入れるのか、それとも より緊密に統合するのか、という点を含んでました。
I think for reasons of simplicity and for efficiency and time pressure we opted for the simpler model, which is the one that I had proposed that gave us the 32-bit extensions but without having a mode bit and without having a huge difference in the instruction sets. As I mentioned earlier, the price for that was we kept the eight-register model which was a drawback of the X86, but not a major one.
[Crawford:] (続き) I guess in addition I got half credit for the register extension because I was able to generalize the registers. On the 8086 they were quite specialized and the software people hated that too. One of the things I was able to get into the architecture was to allow any register to be used to address memory as a base or an index register, and was even able to squeeze in a scale factor for the index.
Z8Kや658xx、16Bit～でもOK
使いにくい6502や8086で仕事をしてきた人達のほうを
今では尊敬したい
その原因は何？
http://www.logsoku.com/r/i4004/1009359454/
>>615 名前： ナイコンさん 投稿日： 03/04/29 08:47
>
>コンピュータなるものが、日本原産だとしたら
>http://www.logsoku.com/r/os/994589053/
>
>>80 名前：Be名無しさん[sage] 投稿日：03/03/11 15:33
>>5年くらい前に、異世界もののゲームに使う設定として作ったコンピュータの規格がある。
>>
>>12ビットワードCISCで、アドレス空間16メガワード、メモリバス・データバスとも24ビット幅で
>>4キロワードセグメントのMMU搭載CPU、動作クロックは2MHz、メモリは旧型が500kHz、
>>新型は1MHz駆動で、いずれも不揮発性。
>>
>>外部記憶は不揮発性電磁気メモリ（バブルメモリのようなもの）のカセットモジュール
>>（高価で容量は少ないが、高速）と磁気テープ（シーケンシャルアクセスのみだが安価）。
>>
>>プリエンプティブマルチタスクOSが稼動するも、UIはCUIのみ、
>>社会環境としては都市部では4096wps(word per second)のパケット回線が敷設済み。
あと、周辺回路の流用も大きい(8080からの流れ)。
http://www.logsoku.com/r/i4004/1009359454/
>>615 名前： ナイコンさん 投稿日： 03/04/29 08:47
>
>コンピュータなるものが、日本原産だとしたら
>http://www.logsoku.com/r/os/994589053/
>
>>80 名前：Be名無しさん[sage] 投稿日：03/03/11 15:33
>>5年くらい前に、異世界もののゲームに使う設定として作ったコンピュータの規格がある。
>>
>>12ビットワードCISCで、アドレス空間16メガワード、メモリバス・データバスとも24ビット幅で
>>4キロワードセグメントのMMU搭載CPU、動作クロックは2MHz、メモリは旧型が500kHz、
>>新型は1MHz駆動で、いずれも不揮発性。
>>
>>外部記憶は不揮発性電磁気メモリ（バブルメモリのようなもの）のカセットモジュール
>>（高価で容量は少ないが、高速）と磁気テープ（シーケンシャルアクセスのみだが安価）。
>>
>>プリエンプティブマルチタスクOSが稼動するも、UIはCUIのみ、
>>社会環境としては都市部では4096wps(word per second)のパケット回線が敷設済み。
理想を追い求めるより(68000)、その時点で可能な範囲での
適度なもの(8086)を作り上げた方が良い結果が得られるということも学んだ。
マーケティングや運の違いもあっただろう。
で、ここからはこの板やスレにはそぐわないかもしれないけど、
最終的に性能（主にスピード）面でも680x0って80x86に負けてるよね？
この要因はどこにあったのだろうか、と。
アーキテクチャの問題で高速化が難しいわけじゃなくてお金の問題？
十分に金をかければ68も行ける所まで行けるのかな。
>>10
ビッグエンディアン、リトルエンディアンも好みが分かれそうだね。喧嘩するには面白そうな話題だね。
8bit時代からモトローラ好きだけど、普通に考えればリトルエンディアンが自然だよな。
それと国内では両者にすがるNECｗ
これらが独占してんだから他CPUに余地は無いだろうな
アーキテクチャの問題で高速化が難しいわけじゃなくてお金の問題？
十分に金をかければ68も行ける所まで行けるのかな。
>>10
ビッグエンディアン、リトルエンディアンも好みが分かれそうだね。喧嘩するには面白そうな話題だね。
8bit時代からモトローラ好きだけど、普通に考えればリトルエンディアンが自然だよな。
クイーンエイリアンとリトルエイリアンなら
http://www.logsoku.com/r/i4004/1009359454/
>>615 名前： ナイコンさん 投稿日： 03/04/29 08:47
>
>コンピュータなるものが、日本原産だとしたら
>http://www.logsoku.com/r/os/994589053/
>
>>80 名前：Be名無しさん[sage] 投稿日：03/03/11 15:33
>>5年くらい前に、異世界もののゲームに使う設定として作ったコンピュータの規格がある。
>>
>>12ビットワードCISCで、アドレス空間16メガワード、メモリバス・データバスとも24ビット幅で
>>4キロワードセグメントのMMU搭載CPU、動作クロックは2MHz、メモリは旧型が500kHz、
>>新型は1MHz駆動で、いずれも不揮発性。
>>
>>外部記憶は不揮発性電磁気メモリ（バブルメモリのようなもの）のカセットモジュール
>>（高価で容量は少ないが、高速）と磁気テープ（シーケンシャルアクセスのみだが安価）。
>>
>>プリエンプティブマルチタスクOSが稼動するも、UIはCUIのみ、
>>社会環境としては都市部では4096wps(word per second)のパケット回線が敷設済み。
>>基本的にこの構成のまま(小幅な改良は続いているが)実に半世紀近くもこのままで
>>安定してしまった世界…というのを想定した。
>>
>>感覚的には、パソコンが8bitから16bitに移行する端境期の雰囲気のままと思って良いかと。
>>
>>
>>この世界の言語は日本語のアナグラムで、コンピュータへの入力は母音5音＋子音10音
>>＋記号等の＋αのキーボードから音節－文節変換で記述、
>>表記は縦書きで右から左に流れ、表示は初期にベクタースキャンCRTが使われたものの
>>すぐに廃れ、主流はレーザースクリーン。
>>
>>技術世代がアンバランスなのは、技術の更新が遅いのんびりした世界という設定から。
>>社会環境から風俗、技術背景、果てはこのネタのコンピュータの命令表まで作ったけど、
>>企画そのものがポシャってしまい、日の目を見ることはなかった…
>
>>12bitと変則的だが、なかなか面白そうな発想。
多分これだな
引用元のスレはさすがに行方不明だった
ハードを組むときD15～D08が偶数番地になってしまうことに気付いて
愕然とした。それは違うだろと。
今は下位バイトが下位アドレスになるのが自然だと思っているリトル信者。
ってわかんねぇだろうなw
無理ってことはないだろう。技術があればどうにでもなる。
そうやって無理と言われるようなことx86は乗り越えてきたろ？
それとも得意のレジスタ拡張だったっけ?
8086に8085の互換性を持たせたモノが8088だし。
> 8086に8085の互換性を持たせたモノが8088だし。
つりかバカとしか思えない。
確かに違和感あるな。
ただ周辺ICとの互換性って意味ならある程度わかるかな?
「周辺ICとの互換性って意味ならある程度わかる」のは、>>27当人だけだろ。
一週間前の恥を丁寧に上塗りか。
8086の後に8085が作られたとか思ってたけど違うの？
8080 1974年4月に発表
8085 1976年3月に発表
8086 1978年6月に発表
8088 1979年6月に発表
8085 … 8080に周辺プロセッサを統合
8086 … 80系の16bitCPU(86系)
8088 … 8086のデータバス8bit版
おまけ
80186 … 8086の周辺プロセッサ統合+小改良版
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E5%88%86%E9%87%8E%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E5%AF%BE%E7%AB%8B#i80x86_.E5.AF.BE_MC680x0
当時リアルに買い求めたユーザでないと判らない点が多すぎる
そこまで把握してたら、本が出せそうだが
HD6309だろ
もしくは
HD68HC000はあった
mmu付きでいいなら020なのかな？
でも386->>486の進化と030->>040はやっぱ同じような印象を持ってるので、386の対抗はどうしても030って印象なんだよね。
8085の売りは5V単一電源で動くことだよ。マルチ電圧なスイチング電源が高価だった頃だし、
5V単一は電源を簡略化できるということで意味があった。8080は三電源。
8086はあまり売れた石じゃない。国内の大口ユーザといえば、ファナックかな。8085だとTEC。
IntelHex形式のバイナリをL/HでスプリットしないとROMに焼けないのがネックだったのかも。
だから8088が…。アセンブラのソースコンバーター(8080→8086)なんかもIntelは配布してた。
安田寿明のマイコン三部作の３巻目に8085の紹介が載ってて、Intel-Japanに電話かけて
普通に手に入るか確認したことがあったなあ。今は無理ですとか。一般的に入手可能になった
のはけっこう後かもしれない。IBM-PCが正式採用するまで、8080のユーザはむしろZ80へ
流れて、8085には来なかった。8086だって5MHzなら6MHzの選別Z80の方がマシ。という企業
ユーザも多かったね。
コンシューマ系しか知らんのでしょ？
ICE も 68020/80286 ぐらいまでは普通に使ってたよ。
まあ、数百万レベルだから個人がそうそう買えるもんじゃないけど、ハードから
開発している現場だとあるとないじゃデバッグ効率が全然違うから、普通のまと
もな企業なら設備投資するのが当たり前だった。
ちなみに Z8000 と言えば、'82 に開発された Pole Position が有名。
まあ、8086/68K に比べれば陰が薄いのは否めないけど、流産と言うほどでもない。
あと、俺はバイトで ASM86 使って普通に制御機器開発もしたことあるけど、
> CP/M86のASM86もDOSのMASMにしてもHexコードを出力するためには役不足。
って、どこが役不足だったの？
CP/M86が動くようになったのは81年頃。70年代末から80年頃までの間の8086のソフト開発
はintelのtool使うしか道がなかった。ああ、CP/Mにクロスがあったかな。CP/M86のASM86
もDOSのMASMにしてもHexコードを出力するためには役不足。制御機器開発向きではなかった。
まともな開発toolが無かったが故に流産したたのがZ8000。YamahaのYIS位か。ソフトが無くて
実機がほとんど出てこなかった。
68000は16bitCPUでは一番前人気が高かったが、初期はtool不足だった。だいたいサンプルが
一番遅れてでてきたし。それでも、83年以降、Mac/Amiga/AtariSTと68K採用マシンが輩出して
から、小規模な言語処理系が86系なみに色々出てきていたようだね。実機があればソフトも
たくさん出てくる例かも。
8/16マイコンの初期は、DECのPDPとかVAXとかがクロス開発に使われることもあったが、
大企業や研究所レベル。8bitCPUはICEなどハードウェアのデバッガが作りやすかったから
選べるほどに色々あった。16bitCPUが16MHzを越えた頃からか、そうしたデバッガが難しく
なって数が少なくなったのは。
コンシューマ系しか知らんのでしょ？
ICE も 68020/80286 ぐらいまでは普通に使ってたよ。
まあ、数百万レベルだから個人がそうそう買えるもんじゃないけど、ハードから
開発している現場だとあるとないじゃデバッグ効率が全然違うから、普通のまと
もな企業なら設備投資するのが当たり前だった。
ちなみに Z8000 と言えば、'82 に開発された Pole Position が有名。
まあ、8086/68K に比べれば陰が薄いのは否めないけど、流産と言うほどでもない。
あと、俺はバイトで ASM86 使って普通に制御機器開発もしたことあるけど、
> CP/M86のASM86もDOSのMASMにしてもHexコードを出力するためには役不足。
って、どこが役不足だったの？
というと民生(機器・製品)業界で、早い話、家電メーカーみたいな街の店頭販売される
ような一般製品の業界。対語はインダストリか。プラントから自動工作機械など。他に
ラボ系というか研究開発向けっていうのもあるな。どれといわれても困るけど。
Z8000は、確かMSのXenixにZ8000対応があって、それを搭載したUnix系の開発機器
をZilog自身が売っていたはず。だけれど、終にZ8000用のICEは出る出るといっては
みたものの、作られなかったはず。この点が命取り。Motorola のExormacsではたぶん
68000のICEがあったかも。よく知らない。国内でよく使われていたのはHPの64000。
あとIntelのMDS。MDSのICEは85/88/86を使ったことがある。
ASM86というと俺的にはIntelのASM86。DRIのASM86は確かにHex出力すると記憶し
てるが、リロケータブルじゃない（リンカもロケータもない）絶対番地記述なコードしか書けない。
アセンブラ制御ディレクティブもCP/Mのasm.comの8086焼き直しな印象。
MSのｅｘｅはロードタイムリロケータブルなコードでROM焼き向きではない。comファイルは
CP/Mのcomファイルに似た100Hオフセットなバイナリだが、smallモデルだけ。コード中に
セグメントレジスタに直値すればDataエリアをRAMマッピングできるかも。という位。
MASMはインテルのASM86に近似したアセンブラ記述ルール(segmentディレクティブなど)
だけど、セグメントの扱いがヤワなサブセット。インテルASM86だとストリング命令には
セグメント指定のオペランドが必須だけれど、MS/DRIはいずれも省略OKだったような。
いずれにせよ、OSオンマシン上で走るコードのためのアセンブラだから用途方向が違う
のは仕方ないことだけどね。
> ASM86というと俺的にはIntelのASM86
だからそれのどこが役不足なの？
.exe ファイルとか .com ファイルの事をグダグタ書いてるのもすごく
素人臭いんですけど。
>>48
まあ、当時の ICE は結構壊れやすかったし、未完成な所もあって、
まともに動かないコマンドとかコマンドの投入順序を変えると動作が
おかしくなるとかが結構あったから、回避するための Tips を書いた
ノートが ICE と一緒に置いてあったな。(w
あったんで面白そうなので参考までに。アルゴリズムは同じでも、実装言語
が異なる。あたりまえだがバイナリは完全に違う。
CP/MのCBASICが糞遅くて、MSのBASICでもPC版はApple版の2.4倍位速い。
LISA-BASICはAppleIIとほぼ同速度。ｗ 68000は素でも8087+8086と同じくらい
の速度が出せたらしい。それでも当時のIBMの中型・大型は10倍速い。今時
のC2DなCPUなら、たぶん0.07秒くらいか。ｗ
Language Version Rel RMS Err Time Bits Mant Grd
CBASIC2/Eagle II 4.56E-6 2740.0s 25.9 24 NO
Applesoft II+ 2.38E-7 488.1s 33.1 32 NO
IBM PC/BASICA (S.P.) 1.10 6.83E-5 205.0s 25.0 24 NO
Applesoft w/DTACK 1.29E-9 34.6s 40.7 32 YES
Tasc w/DTACK 1.29E-9 24.5s 40.7 32 YES
IBM PC/BASICA (D.P.) 2.00 1.41E-14 962.7s 57.2 48 YES
LISA 68000 BASIC 9.30E-14 500.0s 54.4 53 NO
DEVELOPMENTAL 68000 PASCAL 4.60E-17 250.0s 65.4 53 YES
IBM PC, COMPILED (SEE TEXT) 2.21E-14 173.0s 56.5 48 YES
DTACK 68000 #2, HALGOL/48 4.10E-12 23.0s 49.0 48 NO
IBM PC w/MICROWARE 8087 9.31E-14 21.0s 54.4 53 NO
DTACK 68000 #1, HALGOL/48 4.10E-12 19.2s 49.0 48 NO
DTACK 68K/16081 (predicted) 1.30E-13 4.0s 54.0 53 NO
IBM 3031 FORTRAN SAS (SAME) 2.76s 52.7 48 YES
IBM 4341 gp2 FORTRAN SAS 3.09E-13 1.86s 52.7 48 YES
IBM VS FORTRAN (S.P.) V.3 1.13E-3 1.41s 20.9 24 NO
http://web.archive.org/web/20080116151803/http://www.amigau.com/68K/dg/dg24.htm
BackTraceとか殆ど意味無くて、単にLoaderだったｗ
> ASM86というと俺的にはIntelのASM86
だからそれのどこが役不足なの？
.exe ファイルとか .com ファイルの事をグダグタ書いてるのもすごく
素人臭いんですけど。
>>48
まあ、当時の ICE は結構壊れやすかったし、未完成な所もあって、
まともに動かないコマンドとかコマンドの投入順序を変えると動作が
おかしくなるとかが結構あったから、回避するための Tips を書いた
ノートが ICE と一緒に置いてあったな。(w
とかコマンドの投入順序を変えると動作が おかしくなるとかが結構あったから
って、いつ頃のどの会社のICEなんだろ？ オリエンタルとかのレンタル
品を使ってたな奴らが、故障品を送りつけてきた。とかありそうだね。
4bitから16bitのデバッグtoolやICE類は色々と弄ったことがあるが、
あれは壊れるんじゃなくて壊すものだね。一番多いのはCPUソケット
に差し込むアタッチメントの足を折るとか逆さしとか。そういう初歩的な
事故で壊すのはたいてい外注のソフト屋。始末書書かせたこともあるなｗ
ターゲットがまともで扱いを心得ていればそうは壊れたりしないものだ。
俺の近くで「壊れた」ことはないな。
岩崎のZ80のICEなら手元にある。不要廃棄になるんで随分前に持ち
帰ってきたもの。よく知られたことだが、C-BUSのインタフェースに難があって、
ICEが9801を選ぶ。ｗ 386機な9801とかでないとうまく動作しない。PEN-IIな
9821ではダメダメなんで、今は押し入れのゴミと化してるなあ。
> いつ頃のどの会社のICEなんだろ？
8086 時代のやつはメーカー忘れたけど、その後の 80186/80286 時代はソフィアシステム
のやつ使ってた。型名は流石に覚えてないけど、PC 連動じゃなくて、PC 機能を組み込ん
だ一体型だったから結構重くて移動が大変だった。
>>53
> 可搬性が無いので仕事では使わなかった。
そんな結論ですか...、アセンブラに可搬性を要求すること自体に無理があると思うが...。
>>58
ノスタルジーにひたるなら値段はその人の思い入れ次第だからなんとも言えないけど、
冷静に考えたら今時２万の価値はとてもないと思うよ。
○レンタル品を使ってたなら、奴らが、
DRI/asm86, DOS/MASMに持ち込んでアセンブルするとエラー多発。
それだけの理由だな。可搬性が無いので仕事では使わなかった。
> いつ頃のどの会社のICEなんだろ？
8086 時代のやつはメーカー忘れたけど、その後の 80186/80286 時代はソフィアシステム
のやつ使ってた。型名は流石に覚えてないけど、PC 連動じゃなくて、PC 機能を組み込ん
だ一体型だったから結構重くて移動が大変だった。
>>53
> 可搬性が無いので仕事では使わなかった。
そんな結論ですか...、アセンブラに可搬性を要求すること自体に無理があると思うが...。
>>58
ノスタルジーにひたるなら値段はその人の思い入れ次第だからなんとも言えないけど、
冷静に考えたら今時２万の価値はとてもないと思うよ。
z80のiceウラヤマシスｗ でもうちも先日98FAが死んだな…
オク見てたら、出物があったよ。PC-9801DA込み。
DAと言うのがミソ。DAがZ80用の岩崎ProIceを走らせるための最速な9801
かもしれない。その昔、486機が出始めの頃、BXだったか、機種名忘れたが
速かろう良かろうで用意した486な９８がダメで、結局DAをわざわざレンタルして
その場をしのいだ。ということが実際にあった。岩崎通信（ガンツウ）じゃないよな。
岩崎技研。今はもう逝ってしまってて無い。
これにProASMと組み合わせて使うのが、98的Z80クロス開発のベストマッチだと思うなあ。
MSXに差し込んで弄りたい人向けｗ
http://page13.auctions.yahoo.co.jp/jp/auction/r41158194
そんなことは開発者の常識だから言うまでもないこと。
ところが、人間には「うっかり」があって、考え事とか上の空で
作業してると、なぜかターゲットのCPUソケットが2段のお重に
なってたりすることがある。ｗ だもんで、ソケット外しの時に
注意喚起のために、わざわざソケットを2段重ねとかして使って
た奴を見たことがある。
某修理会社から聞いた話では、基板型のエミュレータ
（日電のEVAKITみたいな奴）の電源の±を逆接続して全焼させちまった
基板を修理受け取りしたことがあるとか。ｗ
プロでも間違うときは間違うのが、人間。
マーフィーの法則が流行った頃のオヤジネタでこんなのがあった。
『納期が近づくとデバッガが必ず壊れる。』
ああ、確かにそんな名前だったような気がする。
> 約一年 回転寿司状態だったと解釈していいのかね？
そんなわけないと思う。
入札履歴 - 全ての入札履歴 を見ると
[10月 7日 23時 54分] オークション開始。数量： 1 で 20,000
ってなってるから。
あと、この出品者 76件も出品してるけど、全部開始価格高すぎ。
Gateway のマウスパッド 2,000円とかソニーの古いカタログ 5,000円
とか、とてもあり得ない。
欲しいといえば欲しいけど、無くても全然構わない物だし必要でもないから、待とうｗ
パソコンと言えないほど高かった(オフコンを名前変えただけだけどね)
快適なアセンブリ言語でのコーディングライフを満喫できるよ！
面白味はないな。
多分レジスタを増やすだけだろうし。
命令もブランチ命令とか増やしたりしても、しょせん、だし。
まあ、その方がすっきりしてて扱いやすいだろうけど。
割り当てる所にあるよな
SIMDなんかすっきりとすると思う
これにARMのThumb命令なんかを組み合わせると最高
x86はもはやコードの汚さはとうに我慢の限界を超えている
特にx86-64なんかはひどすぎる
レガシー故の不幸というか、それでも真性RISCよりはコード効率マシな命令が大半だしとでも痩せ我慢するしか
恨むならAMDを恨むしかないねぇ…
x86命令自体は当時汚いとかさんざん言われたけど、μopに分解して実行するようになってからは
むしろコーディング段階で符号化済みのコンパクトな命令セットとして逆に高評価とか、
まあ評価なんざ世相でどうにでもなるみたいな笑い話で
ゲーム機とかに、68Kが多かったのはなぜ？
それでSONYは四苦八苦してるけどな。
最初は高価ではあったけど。
メガドラ以降値下がりした68kより割高だった
開発環境の充実って意味では86系が優れていたけど
コピー対策の意味でも非主流系が望まれるという要素も
http://www.logsoku.com/r/i4004/1009359454/
>>615 名前： ナイコンさん 投稿日： 03/04/29 08:47
>
>コンピュータなるものが、日本原産だとしたら
>http://www.logsoku.com/r/os/994589053/
>
>>80 名前：Be名無しさん[sage] 投稿日：03/03/11 15:33
>>5年くらい前に、異世界もののゲームに使う設定として作ったコンピュータの規格がある。
>>
>>12ビットワードCISCで、アドレス空間16メガワード、メモリバス・データバスとも24ビット幅で
>>4キロワードセグメントのMMU搭載CPU、動作クロックは2MHz、メモリは旧型が500kHz、
>>新型は1MHz駆動で、いずれも不揮発性。
>>
>>外部記憶は不揮発性電磁気メモリ（バブルメモリのようなもの）のカセットモジュール
>>（高価で容量は少ないが、高速）と磁気テープ（シーケンシャルアクセスのみだが安価）。
>>
>>プリエンプティブマルチタスクOSが稼動するも、UIはCUIのみ、
>>社会環境としては都市部では4096wps(word per second)のパケット回線が敷設済み。
AMDはどうなんだろ?
苦しくなってきたらやるかな。
MDで値下がりしたってMDが意識したアーケードは既に68000なんだし
MDで下がったから使われ始めたわけじゃない
どちらもレジスタ・命令ともにわかりやすかった。
そのかわり、裏技は少なかった。
アーケードでは、やはり68Kの、32bitデータの扱いやすさが良かったのでは？
内部16bitでも、アセンブラレベルで16bitの制限気にしなくて良かったし。
特にメモリアクセスとか。
ゼビウスの頃は、Z80とか、とにかく裏技使ってでも速く走る事が大事だったけど。
世代・時代的に違うけどね。
ゼビウスなんか、Z80 基盤5枚組みなんだったっけ。
そういえば、Z80 二基以上搭載PCなんてなかったなぁ。
MZ3500とかFP5700とか、有ることは有るぞ。
もっともサブをI/O制御やメモリ管理に使ってたけれど。
まあ1個はFDD用だったけど、使おうと思えば使えたはず
シーナがそれであの高速出したって記事みたなぁ。
その点、FM-7 のサブCPUは、直接的には、まったく
2個目として使えなかった。
クロックアップバージョンもなかったし。
スプライト使えるVDP載せてたらなぁ。
って、すでにチップの話から外れてるww
MZ-2500って、Z80B 6MHz 一個だとおもってた。
Z80って、制御用にも使いやすいのかな。88のFD制御にも使われてたしね。
1000足りないぞ。
業務用ゲーム機・パチスロ機向けに各セカンドソースが大量生産してたこともあり、
カスタムチップは言うまでもなく周辺LSIに比べてもZ80ははるかに安かった。
当時パチスロ機で6809使ってたのは一社だけだったな。
6809でも似たようなもんだし。
6809でちゃんとマルチプロセッサしてんなーと思ったのは
ナムコのアーケードゲーム基盤くらいだったか・・・・
このせいで16bitCPUへの移行が早まった、と思ってる。
処理能力では8bitと大差なかったしな
あれば当然使いたくなる、でもバスが狭いと
16bitのスレなのに。
で、最近x68kコンパクトのを2台オークションで買ったんだよね
でもこいつ、コンデンサーがそのうち壊れる事で、有名らしーんだよ
先の雑誌まだ持ってるから、ばらして部品とってワンボード作ろうかな
いまさら不便なもの作っても、とも思うけど
憧れを実現して男になるか、大人として合理的に生きるか
あなたなら、どうする
メガドラかピコの初期型でも68000は取れるし、未使用CPU単体でも500円ぐらいだと思うよ。
http://www.intel.com/products/embedded/processors.htm?iid=embed_portal+hdprod_processors
ARMほどではないが結構資産がある
まあ、8bitに毛が生えたような奴だったが。
今でこそ富士通下のPFUだけど、当時のLKIT-16とか松下系の石多く使われてた。
同じ半々のユーザックと一緒になってPFU。
名前は1/3づつだが出資はそのまま足して2:1:1。
もっとも、パナは数年前に手を引いて今は3:1になったが。
…Pいらんじゃないか(~_~;)
ひょっとしてふたりぐらいかな?それとも一人で自演?
もう長いことわざとずれたこと書いて反論を待つという
釣りをやってるよ
わざとじゃなくて本当に無知なんだと思う
さすがにZ80厨はこっちには来れないな。
妄想から一生抜け出せないわけだから
1年ぐらい放っておけば消えるのか？
あまり長く続くようなら規制議論板に通報しようぜ
当時64ビットプロセッサの需要なんて影も形もないだろ
需要なんて関係ない。
むしろ無いうちから始めるのが吉。
68000だって32bitなんて必要無い時に作られた。
もちろん作ったとしても68000のときと同じで欠陥だらけだと思うけどさ。
8086が普及した原因もセグメントモデル
実際に載せるメモリが数百KBとか
せいぜい1～2MB止まりの時代だしねえ
通信どころか広帯域のファイルI/Oですら
一度に64KB以上もバッファを取ることなどまず無い時代、
GVRAMさえ1プレーン64KB越えなどまず無い時代に
セグメントの制約で実現を断念するようなものとなると
実際何があったかってお話
68kは010ですらベクタの扱いに互換性が無くてOS側で対処が必要だったし、
020もさらに専用にコード書かないとOSうら動かなかったし
CPU1基でいいシステムでもバスコントローラを外付けしなければならない高コストCPU
030でやっとそのあたり改善されたけど、386と比べるともうな…って感じだし
040に至っては最後まで量産品が出てこなかった欠陥石
そりゃ負けるべくして負けた、としか言いようが無い罠
まあ68kは夢だけは見せてくれたよ
680x0の本来の設計思想は良かったと思う。
しかし、互換性に関しては680x0は屑としか言いようがないな。
夢だけ見させてくれたという意見は>>144と同じだな。
何勝手に個人用のコンピュータで使用する事だけを前提にしてくるわけ？
ﾏｼﾞでかなぐり捨てンぞ？
ただ読み込みが遅いだけでなく8bitバスで繋がってたりし兼ねない勢いで、
そこへ68系を使うに至っては悪夢に近いものがあったりした罠
基本設計の美しさだけならMIPSやPowerの方が遥かに美しいし
だけどそんなものは実際の製品に納まってしまえば外からはどうでもいいお話で
意識してパタンと切り替えてやれば済む話で、
ROMとRAMが混在してたりバンクメモリ切り替えまくったりするような用途では
ポインタの有効範囲を明示できるって意味でも意識上むしろ楽だったくらいで
アホはよくほえる。
V50使ってたときは64K超えてるセグメントが欲しかった。
今はもうアセンブラ使わないしメモリ管理はOSの仕事になっちゃったから、どうでも良い。
アドレス管理する必要は感じなかったな当時。
そもそも、相対アドレスとか絶対アドレスとかを意識しなくてもプログラムできるのがセグメントの利点だと思うのですが...
ベースがPCみたいに変化し続けるレジスタじゃない分、使いやすかった。
使いもしない馬鹿がブリブリ文句だけは垂れたけど、
68kで24bitや32bit幅のセグメントが存在してたら
神とか言ってたろうにな
確かにサイズがデカく取れれば便利な機構だとは思うが実際アレだったから
ROMに置いておくべき固定データならともかく、RAMに置くデータやデバイスのレジスタはPC相対という考え方で位置を決めてはイカンよ。
シンプルで合理的な実装だと思うが。
レジスタの本数的にPC相対に拘らなくてもなんとかなるっちゃなるけど、やっぱり作る物によっちゃセグメントライクな機構があれば便利。
最近、トレノ・レビンが話題になっているね。
終わり。
【企業】ハチロク復活！ トヨタ、小型FRスポーツ「FT-86 Concept」 水平対向4気筒 6速MT 中高年の車好きに向け★１２
http://www.logsoku.com/r/newsplus/1255107659/
機能と関連あるデータをコードとまとめておくってことはスレッド分コードも展開するの？
自己書き換えしないとマルチスレッドに対応できないなんてｗｗ
タイマー割り込みの時レジスタやり繰りして切り替えればいいんじゃね。
「仕様書の上では」が抜けてね?
「仕様書の上では」が抜けてね?
68020 VS 286 処理速度で負けて機能面で並ばれて
68030 VS 386 処理速度は勝てたけど機能面で追い抜かれ
68040 VS 486 処理速度も機能面も突き放された、おまけに最期まで試作だけ
030のMMUなしエディションが存在する時点でメモリ廻りの作込みが弱いとさらけ出してるような物だし。
68040はおろか68060だってちゃんと製品出てるんだが?
その後も汚いリホームの積み重ね
ただそれが人間にとって使いやすかったりする
インテルの社訓は「互換性か死か」だから仕方なかろう
互換性を無視していいならItaniumみたいな例があるが
さっぱり売れないだろう
中身見たような言い草だな。何が弱いのか問いたい。
仮想メモリとそれに上乗せする形で実装される仮想マシンが、MMUが外付けであることによる技術的にどのようなメリットとデメリットが存在しようが、システムを使う立場から見れば弱い。
モトローラのプロセッサはエンジニアに本来なら払わなくてもよい本質的でない余分なこと、MMUの有無を意識すること、を強いている。
ライバルであるインテルのプロセッサは386以降ならエンジニアは同じ手法で利用できる仮想メモリ、仮想マシンの機能があるのが当然としてシステムを設計できる。
68030が、メモリ管理というOSが必要とする根本的な機能において、すべてのエディションで機能的に全くの同一でないというのは弱点以外の何者でもない。
考えもあったんだろうさ。なんか欠陥でもあるのかと思ったよ。
作り込みが弱いってのは脳内の妄想から出たって事ね。叩きたいからって適当
な事書いちゃ駄目よね。
286はMMUが無いからゴミだって68信者が言ってた。
有る。過疎スレなんかでは特に顕著。そうなるとスレの進行が止まってしまい機能
不全に陥ってしまう。大事なのは住人が散ることなく荒らしをスルーするという事が
求められるわけですよ。MSXスレなんてひどいもんでしょ。
対話でいなくなった荒らしはいないと言うけどスルーでいなくなった荒らしもあまりい
ないけどね。NGにぶっこんで放置するしか無い。機能不全よりはマシだから。
この68粘着叩きの特徴みたいだな
どうやったらこういう陰気落武者が生まれるのやら
キチガイがデンパ撒き散らすスレなら落ちてもかまわんがな
初耳。
http://bboah.claunia.com/mc68060.html
MC68060は1999年に出たとあるな
MMU/FPUありの75MHz版のMC68060RC75が見つからず
XC68060RC75も入手困難だったという話に尾鰭が付いたんだと思われる
注文は10個単位のようだが
アクセラレータで060搭載したのはあったように記憶してるけど
富士通のKシリーズ等には68060を載せてる機種もあったよ。
MPUアクセラレータはAmiga、Macintosh、X680x0とかに出てたね。
それとも非PC互換機路線では商売にならないという判断から?
AT互換機は簡単に作れるし、無理して引き伸ばす必要も無いってことじゃないのかな。
『68kには夢があったぜ』
『ああ。短けぇ夢だったがな』
>PPC
88000の事も思い出してあげて >_<
親に捨てられた不憫な子
…悔しいがIntelの技術だか企業体力だかは凄かった…orz
んなもんはないよ。
IBMが採用したから脚光を浴びたラッキーボーイだよ。
昔も今も根性は悪いしね。
だからこそのPPCだったのかも知れんが、発想まで違うとユーザーは愚かディーラーまで戸惑っちゃったからね。
6809から16Bit、32Bit(そして64Bit)と地道にアップしていった方がよかったんじゃないのかな。
そしたら(細々でも)生き延びてたかもね。
どんなプロセッサによらずね。
悪魔の所行だ!
インラインアセンブラで済ませられるレベルまでが許容範囲。
MS-DOS環境なら何度かやったことあるけど、今はもうノーセンキュー。
意図がはっきりしやすくむしろ保守性は高い
Cでプログラム組んだら、nearとかfarとかhugeとかで悩まされるけど
セグメントモデルではないプロセッサでリロケータブルなプログラムを作るには、リロケータブルなコードを書く必要があるだろ?
今だとOSとか、ハードに近いとこでもほぼCかC++辺りじゃね?
割り込みハンドラ（中身じゃなくて受け渡しする部分ね）なんだよ～
68kの世界に引きこもってるからいいけどさ…
その辺の処理を書き始めたらOS作るのと大差ないから。
ビンゴ…68Kだと楽なんだけどね…
納得しかけて気が付いた
それ、OSの仕事なんだからしょうがないだろ?
ひょっとして16進数べた打ち？
アドレス8Bitのときと同じで倍にしておけば24Bitまで使える。
VRAMマッピングしても充分なエリア。
漢字だって1WORDで扱えるし。
やっぱり舶来文化じゃあ漢字?面倒だから字二つ使えよってことなのかな。
１２bitCPUは昔のレスで秀逸なのを読んだことがある。
漫画だか小説だかは忘れたが、その人の作品に使うためのもので
日本でコンピュータが発展した架空の世界。
Z80000って32bitの奴だろう。
今の感覚で見ると。
お茶濁し程度だから使いつづけられたんだろ?x86
競争が成立するぐらいニーズがあった。
68kの倍クロックを開発したとしてもどれだけ売れたかな
むかし、nifの壁でキリ番競争やったっけ。
プロセッサが早くなってもプログラマはたいして楽にならない、機能が増えににゃゴミ屑だと同僚に愚痴った覚えがあるんだが。
x86 でクロックダブラーが入ったのは 486DX2 から。
その前の 486DX/SX で既に基本命令１CPI を実現していた。
そもそも命令あたりのクロック数は減らしようがない。
>>259
68020/68030 は最低でも２クロックかかる。
１CPI になったのは 68040 から。
68000 は最低４クロックで 8086 も同じ。
8086より68000のほうがクロック数が少ないということはない。
６８kとか０１０だと結構クロック消費してような気がする。
x８６に比べればぜんぜん少ないけど。
６８０x０のデータシートが行方不明だ。
３８６／４８６のはあるのに。
x86 でクロックダブラーが入ったのは 486DX2 から。
その前の 486DX/SX で既に基本命令１CPI を実現していた。
そもそも命令あたりのクロック数は減らしようがない。
>>259
68020/68030 は最低でも２クロックかかる。
１CPI になったのは 68040 から。
68000 は最低４クロックで 8086 も同じ。
8086より68000のほうがクロック数が少ないということはない。
さんくす。
３８６のクロック浪費（！）の印象がでかかったから勘違いしてたよ。
この休みに６８０x０のデータシート発掘できれば嬉しいな。
ISBNコードの有無は忘れたけど、値段が入ってなかった非売品。
初期の設計が美しかっただけに残念だ。
一方のx86は当初は設計が醜い石の代表だったけど、
そのころから互換性はしっかりしてたもんな。
3.5千円って、なんでこんなの買ったんだろう?
味噌汁で顔洗ってきやがれ。
まあ実装するとなるとアホかって程高くつく事になる訳だが
x86でSMPに標準対応したのはP6系以降
チップセットの方で対策して486やP5でSMP機の実装もあったけど
って、68KのOS自体よく知らないけど。
それも020以降しか
86系も結局UNIX互換系かNTになっちゃうのか
486やPentiumを1000個とか積んだ
今でいうクラスタ系のHPCもあったけど、OSに何を使っていたかまでは知らん
ひょっとしたら386でもやってたかも
チップセットっていわれる物はいつ頃から出てきたの?
68系は標準機的な存在が無かったから恐らく無いのでは
020系のバスコントローラはバスコントローラであってチップセットではないし
本スレ
http://www.logsoku.com/r/i4004/1154007686/
自演野郎しかいないスレなんかいらねーよ。
スレ数が物語ってるな。
あんまり嫉妬すんなよ。
インデックスレジスタ、スタックポインタは32bit(実アドレスは24bit程度かな)で各々4本。
(スタックポインタは2つで充分?)
ダイレクトページレジスタはどうなるのかな???
コンデションコードはそれなりに追加。
こんなもんでも68Kと比べたら半分ぐらいかな。
取っ付き易さはそうかもしれんな
大概のループ処理なら16本のレジスタだけで回せた
初代8086より圧倒的に早かったのは恐らくこれが原因
bne loop
だけでブロック転送が簡単にできちゃうもんね。
・・・bneだったかな？
もう忘れちゃった。
最近だったら、バッファオーバーフローの可能性を考えて
もう2行付けくわえないといけないけど。
mov cx, siz ;word単位
mov si, offset src
mov di, offset dst
rep movs word ptr es:[di], word ptr ds:[si]
68000
move.l #siz-1, d0 ;long word単位
lea src, a0
lea dst, a1
loop: movem.l (a0)+, (a1)+
dbra d0, loop
ループ用にラベル設定しなくて済む分、x86の方がスッキリしてません？
8086は専用のストリング処理命令があったのでそれは当然といえば当然。
ただちょっと複雑な処理になるとレジスタの役割も処理内容も固定の
ストリング命令は使い道なかった。
まあZ80のLDIRよりははるかに応用効いたけど。
俺みたいなヘボグラマーにとって68はｽｯｷﾘわかりやすくて扱いやすいから好き
86は（俺主観では）変に多機能かつお約束が多くて自分のコードを書く前の段階で頓挫しちゃう
慣れりゃどうってこたぁない。
データの構造化がやりにくいって印象が強かった。
mcc68kってコンパイラについてたアセンブラ。
しかしアセンブラはどのプロセッサのどこのメーカーのをどう使おうがちょっとでも高度な制御構造やデータ構造の構築、管理でもやろうとするとプログラマーへの負担が大きくなる。
といってもZ80、80x86、680x0、PowerPC（G4)、ARMv4、H8、SH3/4ぐらいしかアセンブラは使ってないから俺の意見が絶対とは言わないよ。
x86のプロテクトモードプログラムは裸足で逃げ出した出ござる
PC-ATも悪いんだろうけどね(A20ラインだっけ？とか）
やってられんだろうなあ。
そういやインテルが骨格になるメモリ管理部分のコードを提供してたような
気がするけどそういうのいじくって会社用とか自分用にするのはアウトなのかな。
規制解けたのか?
どういう形態で公開してたかだな。
フリーって事はないと思うが。
もちろんあくまで個人として使うと言うなら別だが。
未来人乙
このスレのペースなら1年後くらいか
頑張れよ
時代はすでに12コアかよ。
コプロありの386DXがアセンブラでコード書いたのが最後だなぁ。
x86は、BPの使い方とかPL/M向けの実装だったのかな
ん？
68000は、IBMのSYSTEM 360を参考にしたんじゃなかったっけ？
186のentry/leave命令のセットがその延長でスタックフレームの転写を明示的に行うんだとか。
「なんちゃら」とかでなくて、局所変数をもつ近代的な言語すべてに必要。
スタック上に局所変数域（スタックフレーム）を形成するため。
ただし 386 以降のように SP 相対アドレッシングモードがあれば、そちら
で代用することも可能。gcc では --omit-frame-printer オプションで
切り替えられる。SP で代用しちゃうと動鎖を手繰れないので、デバック時
にバックトレースできなくなるけどね。
enter/leave 命令はスタックフレームの形成・開放を１命令でやってくれて
便利なんだけど、オンスタックディスプレイを転写する第２引数なんて正気
の人間は誰も使わない。
どれだけの価値があるか不明だったmicro processorとやらの用途が
当初の予想以上に広がりつつあった頃だから。
8086なんて単に8080を16bit化(もちろん多少の命令も加えて)した物かと思ってた。
結果8080の基本構造をおおむね引きずることになった。
16bitCPUを新たに設計したというより8080を16bit拡張したと見るほうが
しっくりくるのはそのせい。
富士テクノロジーとかなんとかいう会社の出してた386/486の解説本だったはず。
技評の286アセンブラ入門だったかも、
よくわかる486でないことはかなり自信あるけど
紙ベースで読んでるからIA32マニュアルではないことだけは確かだ。
実際entry命令の２つめの引数はコンパイラだけが知ってればいいんだよね。
実際いつでも、386のコード書いたときだってずっと0だったし。
> 実際entry命令の２つめの引数はコンパイラだけが知ってればいいんだよね。
いや、コンパイラ作成者でも絶対に使わない。
もう少し詳しく言うと、Pascal や ADA のように関数・手続きの中に
局所的な関数・手続きを定義できる言語で、中間変数（内側の関数など
からみて大域的な、外側の局所変数）を正しくアクセスするために使う。
伝統的には、この目的には静鎖（スタティックリンク）が使われる。
あるいは高速化を狙ってディスプレイ（陳列棚）方式が使われることもある。
通常のディスプレイは静的な配列を１つもっていて、サブルーチンコールの
たびに、その中の１エントリだけ更新する。コピーが必要なのは手続き引数
を使うときだけ。
で、インテルは何を思ったのか、ディスプレイをスタック上にとって、サブ
ルーチンコールのたびにコピーして回るという方法を想定した機能を enter
命令につけてしまったので、みんなの笑いものになったというお話。
引数の数が不定じゃない言語用だな。
あれ？むかしのMS-DOSのC言語で、pascal宣言入れておくと速く（小さく？）なったのは
それのせいだっけ？
それは leave 命令のオペランドの話ね。
呼び出された側がスタックに詰まれた引数をとりのぞく。
今でも PASCAL または WINAPI 呼び出し規約を指定するとそういうコードがでるよ。
なにしろ伝統的な Windows API はほとんどこっちだから。
ただ、昔でも 186 以降を指定しないと enter/leave 命令は使ってくれなかったけどね。
486 以降は単純命令の組み合わせのほうが速かったりするから、今のコンパイラでも使って
くれないかもしれない。
現役プログラマーなんかもそこそこ居る感じ。
というか>>330がどこから来て何を独特の言い回しだと思ったのか気になる。
二段階マイクロコード採用。
それでもトランジスタの約半分はマイクロコードだっけ？
どうだろう？
写真見る限り面積では半分よりずっと小さいけど、
ROM はトランジスタ密度高いからそんなもんかな？
http://www.infonet.co.jp/ueyama/ip/history/1979-m68000.jpg
＃ 6309 はマジでチップの半分をμROMが占めていたが...
マイクロコード： 17bit長×544
ナノコード： 68bit長×336
合計32096bit
http://www.cs.umass.edu/~weems/CmpSci535/Discussion15.html
一次情報は見つからなかった。
な小容量一次元配列に対する操作じゃないと、CPU本来の速度で高速に走らないでしょ。
そういうところを経験してから、x86のセグメントモデル思い出しちゃてさ。
80年代当時の68系のx86系に対する最大のアドバンテージであった、広大なメモリ
空間をシームレスにアクセスできるっていう奴を、IA-32が手に入れたのもつかの間、
性能を出すために結局64KByteや32Kbyte内でちまちま動くような管理されたバイナリ
コードを用意する昨今。
なんか先祖返りっぽい。
そういったアーキテクチャレベルのキャッシュ管理ってどうだか。タスク切り替え時に
明示的にキャッシュをクリアするほうがいい気が。(既にやってるのかな、知らないけど)
そんなチマチマしている最適化はプログラマを疲れさせるだけよね。
そんなもん実装できんわな。2行目は無かったことにしてくだちい
っとすると64bitのアドレスが足りなくなるって事は…
DDR4も未だ行く先真っ暗。
2012年ぐらいから登場らしい。
でもポイントTOポイントで一枚しか付かないらしい。
By WinPC
組込み用の内蔵RAMがメモリ空間に見えてる様にキャッシュしなくても十分速い内蔵RAMがプログラマーに解放される。
64bitとかあるのかな。
アドレスの下２ビットはどうせ０だし、GC用のマーク入れてちょうどいいかもね
どうして68Kを採用したのだろうか？
16本の32BITレジスタで8BIT時代に泣かされたレジスタの不足とももさようなら。
68000は大容量を必要とするホビーストを魅了して止まないCPUだったのだ。
実はX68000には80386採用案もあったんだけど、ホビーストたちは
あの8086を引きずったなんともじれったい命令セットを好まなかった。
レジスタも少なかったし。
多分大して変わらなかったかと。
シャープはどうだったんだろう?
もっとも、日立のように自社製品使えない哀れなとこも有ったけど。
普通にMS-DOSマシンだった方が面白かったと思うよ
V30＋豪華グラフィック＆サウンドのPC-88VAは鳴かず飛ばずだったよ。
ヴォケはそのままそっくり返す。
OSはMS-DOSとなるとNEC、富士通といった先行してる競合他社に勝てると判断したとは思えないから、やっぱりx86系はないな。
機種争いはないし、C信者も駆除。
BASICも速いし、3Dも手軽にできる。
少なくともBASICやってる奴の数百倍以上は確実にCやってる奴がいるだろうにな。
でも、まぁ同意。安く一通りのことが何でも出来る。いい時代ですわ。
＞Ｃ信者ってのが判らんが
bell研究所の工作活動の一環で、市場からBASICを消し去ろうとした。
＞基本的には何時の時代も無いものねだりですよ
オレにとってはこれから飛躍と復権を目指せる時代に戻れる。
もちろん、オレだけじゃあなくて、外野に多くいる日曜プログラマーたちにとってもな。
ここに居たんじゃなくて他スレで涌いて移ってきたんだよ。
ほんと、蛆虫みたいだ。
MAIN STREET
http://www.geocities.jp/courant_de_console/main_street/
妄想だからつっこみ歓迎。
80386/16MHz、コプロセッサはオプションで387。
しかし当時のシャープだから287も視野に入れておいた方がいいだろうか？
RAMは標準2M、4Mにすると価格的に厳しかったはずなので。
16M以上は実装できるようになってたけど最大64M程度だろう。
ピン数の関係でデータ32本／アドレス24本(A25～A2の)で最大64Mバイト、というのがその根拠。
でもコネクタは4～5本程度だろうから1Mとか2Mのメモリモジュールになったろうからコネクタ数の関係で10Ｍ程度が事実上の限界。
3～4年経って容量の大きなメモリモジュールが発表されるようになってから16Mオーバーが(コスト度外視で)実現するぐらいか。
画面、サウンド周りは史実のX68000と同等程度。
ただOSがMS-DOSとすると1M以下に収める為に画面が640×480×4・・・いや640×480×8は実現しているだろう、きっと、たぶん、おそらく。
PCMも8BitADPCMにダウングレードするかも。
FD/HDは史実のX68000と同じ。
HDDは、最初はオプション。
で、SASI/SCSI/SCSI-2と史実と同じような経緯をたどると思う。
なんか面白みが減ったマシンだなぁ。
妄想力が足りない。
640×480×4ってなんだよ、×4って！
640×480×6とか、そういう中途半端に思えるスペックを実現しちゃうのが当時のシャープだろ！←偏見だけど
そんなにプログラムしにくかったの？
超えるとちょっとめんどくさい
386なら64KBの制限もない
64KB制限で苦労するのはC/C++を使った時ぐらい
シングルタスク環境で複数のメモリ空間を平行で考える手間とメリットに
当時のクズプログラマでは想像が及ばなかったってだけの話だよ
当時64KBセグメントで困る用途なんて
パックドピクセルで広大なVRAMをリニアアクセスさせろ、くらいのもんだろ
そんで殆どのPCのGVRAMはプレーン式だった
バカ?
MAIN STREET
http://www.geocities.jp/courant_de_console/main_street/
新しいコト、次々と。
386信者vs.懐疑派の大論争を彷彿とさせる流れだな
富士通側は「サードパーティの希望を充分に考慮して採用CPUを選んだ」という立場だが
実際のところ、X68K市場がかなり立ち上がってたと思うので、当時のソフトハウスとかは
どういう意見だったんだろう？
ただのマイコン少年あがりだった自分としては、その辺の事情に興味がある
アーケードとかは別にして、一般家庭向けパソコン市場のソフトを企画する際
開発環境の充実度/工程とか、クリエイター/プログラマの‘モチベーション’とかw
386と68Kでかなり異なる要素があったんだろうか?
68kと386なら全てにおいて話にならないだろｗ
386ベースならCPUパワーもメモリも十分コンパイラ頼みでいけたと思うし
68系は製品サイクルも86系に１世代近く遅れ気味で市場に出てたし
386は正解だったと思う。同等品の68系を同価格で装備できたのなら議論の余地は(ry
タウンズはCPUの問題より、他のハードの部分が競争力に欠けた気がする
386を引き合いに出すなら68030や68040を比較の対象にすべきではないかね？
DSPをユーザーに開放しなかったのが汚点かね
よくよく考えると、PC/AT互換じゃないのに、よくやったなと＞TOWNS
まあそれを言ったらHuman68K作ったHudsonはもっと偉いけど。
現実と伝説が乖離し過ぎ
IOCSとか使って徹底して将来の仮想化に備えるとかは、あの頃のCPUパワーと
X68に求められてた事を考えれば現実的じゃなかったし。
そうなるとOSというよりDOSでいいんだよね。それ以上されると資源喰われるだけで困る
発売当初からWSレベルのものを本気で求めてた人は違うんだろうけど。
プログラムアドレス空間とデータアドレス空間を分離するハーバード・アーキテクチャを採用することにより、
高度なメモリ保護機能を実現していた。さらに当時としては画期的なマルチタスク動作も可能だった。
MC68000はサン・マイクロシステムズの初代UNIXワークステーションであるSun-1や、
初期のMacintoshや伝説のマシン「Amiga」などに採用された高級かつ高性能で高価なCPUであり、
小売単価で１個２万円している頃・・・。
MC68000を搭載したセガのメガドライブは、れっきとした完成品のくせに・・・。
５００００円？違うぜ！！
１０００００円？いやいや、違うぜ！！
５０００００円？そんな馬鹿なことがあるか！！
なんと、たったの「２１０００円」だぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁあああああああああ！！！
これはもう今すぐ買わないとダメなレベルですね！！
今更メガドライブの宣伝をしてどうするww
メガドラのこと何も知らなかったので、wikipedia で読んでみたよ
1988年10月29日発売ってことは、22年前か～
MC68000 + Z80A + YM2612
おお～、なかなか面白そうっと思ったけど
RAM 64KB VRAM 64KB ←ここでコケたw
まぁ当時の家庭用ゲーム機としては、これでも破格性能&価格だったのかなと推測
製品サイクルは別に遅れているとも思わないけど、
仮想記憶サポートするには２チップ構成となるので、
コスト的にちょっと厳しいものがあったね。
メモリ空間などのプログラミングモデル、実装されている機能から、80286になって
やっと 68000と比肩する機能を得たといえる。（但し演算速度については80286が
68000のほぼ倍程度の性能を有している。）
ttp://ja.wikipedia.org/wiki/Intel_80286
64KBでも大盤振る舞いもいいところだ。
VRAMも少なく見えるかもしれないけど、
ビットマップVRAMは持っていない（スプライトとBGしかない）ので、これで十分。
逆に、全部RAMで持つしか無いメガCDは512KBも積んでいた。
そりゃあ安く作れる訳がないわ…
ROMカセット主体ってことをうっかり忘れてました、なるほど納得。
全発売ソフトの一覧表を見たら、ずいぶん色々(移植作とかも)出たそうなので
スプライトとBGだけであれだけできるのは凄いと感心。
ちょうどTOWNS発表(1989年2月)の直前ってことに後から気付いた
メモリをバカスカ積むようになるのは、CD-ROM媒体になってからの話
現在の携帯ゲーム機(DSとか)のソフト供給媒体がROMであるにもかかわらず
本体にメガバイト単位でRAMを搭載している理由は、
プロセッサが高速になることで相対的に半導体メモリ(ROM)といえど読み出し速度が遅くなってしまい、
それに輪をかけてROMへ繋がるバス幅が狭いという事情から
最大16KB積めるのだけれど、それはゲームカセットの中にROMとして搭載
同時期の他機種は本体内蔵で、価格を押し上げ、敗北する一因となった訳だ。
今から考えると本当のボッタクリ
つうか68000てそんなマイナーなCPUだったとは当時思ってなかった。
放っておけばホイホイ売れそうな筋のいいCPUだったけど
モトローラは営業努力怠ってたのかね。
MC68000の最後の超大型商機はセガのメガドライブだったわけだが、当時のモトローラは既に倒産しかかっていた。
モトローラは当時まだ無名のゲーム機メーカーによる100万個単位の大量発注を受け付けることは
あまりにもリスクが高すぎると判断したモトローラ側が警戒し、セカンドソースを生産していた
シグネティックス社を介して供給することで受け容れたという事情があった。
ちなみに、このシグネティックス製68000はＭＩＬ規格対応だったらしく、
そのためかオリジナルよりもやや大きいパッケージである。
後期のロットには日立製、メガドライブ2にはモトローラ製も採用されている。
そして、セガが使わなかった68000以外の68kファミリーは、結局高価なまま成功しなかった…
セガが開発するハードウェアは伝統的に汎用のプロセッサをそっくりそのまま搭載するため、
確かに任天堂と比べれば弱小の万年負け組ハードだったけれど、
組み込み系では有り得ない数百万個ものオーダーでプロセッサを大量発注・大量消費することから、
セガ一社からの発注分で開発・製造コストを償却可能で、以後価格をガンガン下げられるようになる。
開発するプログラマーにとってもメリットがあり、挙動が不明な専用パーツを使っていないから
コストや開発スケジュールを大幅に圧縮できるという事情もある。
8086がIBM-PCに採用されたのも8080(CP/M)との互換性が大きな要因だったらしいし。
んでボーっとしてればはここまでで終わりそうなんだけど後に286→386→486→Pentiumと
互換性を維持し32ビット化を果たしながら怒涛の勢いで処理能力をアップさせて行った。
開発力も大したもんだったと思う。
元が元だけに伸びしろなかったのはわかるが性能頭打ちすぎ
出てきたときから完成してたから
なんで30移行でないとfreeBSDがどうさしないんだっけか・・・。
FreeBSDは動かない。NetBSDは68030以降で動く。
68000 単体では仮想記憶サポートできない。
68010 から仮想記憶をサポート、ただし外付け MMU が必要。
ワークステーションなら 68010 や 68020 で仮想記憶をサポートした
マシンはいくつかある。
不十分な例外機能しかない 68000 × 2 で、仮想記憶をサポートしたマシン
もあるから >>424 が何を言いたいのかはよくわからんが。
68030 から MMU を内蔵したので、68030 以降の MPU が乗ってるマシンなら
基本的に仮想記憶がサポートされた。
>>427
> 68000のマイクロコード/ナノコード構造や、68020のメモリ間接アドレッ
> シングみたいなものを極力廃して
その役目は 88000 が担うはずだったんだがちょっと遅すぎたな。
仮想メモリ自体は命令が無くてもMMUが無くてもMZのクイックディスクでも不可能ではない
68000 単体では仮想記憶サポートできない。
68010 から仮想記憶をサポート、ただし外付け MMU が必要。
ワークステーションなら 68010 や 68020 で仮想記憶をサポートした
マシンはいくつかある。
不十分な例外機能しかない 68000 × 2 で、仮想記憶をサポートしたマシン
もあるから >>424 が何を言いたいのかはよくわからんが。
68030 から MMU を内蔵したので、68030 以降の MPU が乗ってるマシンなら
基本的に仮想記憶がサポートされた。
>>427
> 68000のマイクロコード/ナノコード構造や、68020のメモリ間接アドレッ
> シングみたいなものを極力廃して
その役目は 88000 が担うはずだったんだがちょっと遅すぎたな。
68030以降だよな、仮想メモリ使える68k系は。
みたいなものを極力廃して、新し目なプロセスで作ればそこそこイケるんじゃ？
と思わせたColdFireも、結局 0.18μm 266MHz止まりみたいだし・・・
まぁ、上にはさらに高効率のPowerPCがあるんだから、当然と言えば当然なんだが・・・
なんと言うか、好きだっただけに寂しい結末だな
freescaleってモトローラミュージアム的な所あんだよ
いまだに6800系チップや68000の末裔作ってんだから
Intelは8080系や8048なんてもう作ってないでしょ
68000 単体では仮想記憶サポートできない。
68010 から仮想記憶をサポート、ただし外付け MMU が必要。
ワークステーションなら 68010 や 68020 で仮想記憶をサポートした
マシンはいくつかある。
不十分な例外機能しかない 68000 × 2 で、仮想記憶をサポートしたマシン
もあるから >>424 が何を言いたいのかはよくわからんが。
68030 から MMU を内蔵したので、68030 以降の MPU が乗ってるマシンなら
基本的に仮想記憶がサポートされた。
>>427
> 68000のマイクロコード/ナノコード構造や、68020のメモリ間接アドレッ
> シングみたいなものを極力廃して
その役目は 88000 が担うはずだったんだがちょっと遅すぎたな。
移動してなかった？
モトローラ→ONセミ→FreeScale
と、2回もスピンアウトしたのかと思っていたら、会社概要見る限り
モトローラ→FreeScale
としか書かれてないのだが・・・俺の気のせいかな？
オンセミは台湾かどこかの会社だと思ってた（恥
・車が勝手にエンストしたりエンジンブロー
・アクセルペダル戻しても車が加速
・ブレーキが効くのにタイムラグがおきて人を弾く
・メーター文字化けか表示が意味不明
・
…プリウスどころの騒ぎじゃない規模の集団訴訟がおこるなｗｗｗ
＞車の電子制御がM$のOSだったら…
>>438
＞人命に直接関わる製品にM$のOSなんぞ怖くて使えんわ！
>>439
＞どこぞの原発でM$のOSが使われてるって話があったようななかったような・・・
今でもWindowsシリーズ(含むNT系)のライセンス事項には
「核施設や救命施設での使用時にのトラブルは保証しない」とか書いてあります。
使ってはいけないというか、俺たちは何があっても知らね～よと（ｗ
某一度倒産した悪徳ＰＣショップに勤めてた時、原発から注文受けたことありますよ（ｗ
高級車にはOS/2
TOYOTAの重役専用車にはMS-DOS
＞車の電子制御がM$のOSだったら…
>>438
＞人命に直接関わる製品にM$のOSなんぞ怖くて使えんわ！
>>439
＞どこぞの原発でM$のOSが使われてるって話があったようななかったような・・・
今でもWindowsシリーズ(含むNT系)のライセンス事項には
「核施設や救命施設での使用時にのトラブルは保証しない」とか書いてあります。
使ってはいけないというか、俺たちは何があっても知らね～よと（ｗ
某一度倒産した悪徳ＰＣショップに勤めてた時、原発から注文受けたことありますよ（ｗ
いくらなんでも制御用じゃないだろうけど。
＞車の電子制御がM$のOSだったら…
>>438
＞人命に直接関わる製品にM$のOSなんぞ怖くて使えんわ！
>>439
＞どこぞの原発でM$のOSが使われてるって話があったようななかったような・・・
今でもWindowsシリーズ(含むNT系)のライセンス事項には
「核施設や救命施設での使用時にのトラブルは保証しない」とか書いてあります。
使ってはいけないというか、俺たちは何があっても知らね～よと（ｗ
某一度倒産した悪徳ＰＣショップに勤めてた時、原発から注文受けたことありますよ（ｗ
Ａ：PL法はあくまでも製造物（有体物）に対する法律なので、純粋にソフトウエアに関してのみにはPL法は適用できないそうです。
製造物とは製造または加工された動産のことをいいます。不動産、未加工の農産物や水産物、
有体物でないサービスやソフトウエア、電機エネルギーなどは対象から外れます。
ソフトウェアについては受託開発したシステムの不具合でユーザー企業が被害を被ってもPL法の対象外ということになる。
コンピュータにプリインストールされたOSやアプリケーション・ソフトも，PL法の対象とはならないとする解釈が一般的。
なぜなら、こうしたソフトは利用者に選択の余地が残されているため，製造物であるコンピュータの一部とはみなせないからだ。
だからこそ、どれだけとんでもない異常な欠陥があろうとWindowsにはＰＬ法が適用されることはないんです。
ただし、不動産でも備え付けの建具や厨房、照明器具などの住宅部品は動産の対象になります。
ソフトウエアもそれ自身はＰＬの対象外ですが、ソフトウェアが産業機器などに組み込まれた製品は
「機器に組み込まれた“部品”の一部」とみなされるためＰＬ法の対象品となります。
だからこそ、自動車や鉄道車両に航空機やエレベーターには長年の実績があり、
バグがほとんどなく、堅実で信頼性が高い「枯れた技術」が使われるのです。
直ちに近くの救急隊員に転院を申し出るか、来世も人間であることを祈りましょう。
諦めて永遠に地獄で苦しむ覚悟します
今と大差ないか…
どうも間違ってるらしい。
ttp://www.st.rim.or.jp/~nkomatsu/mc68k/MC68000.html
これによると、コンテキストの保存はせずに、メモリを踏み外したプロセッサを一旦切り離して、
もう一個のプロセッサでページインとかの処理をやればいいんだと書いてある。
ＭＳの使用許諾は、対集団民事訴訟用でしょう。何書いても刑法上の義務は免れないわけで。でも、うまいんだなこれが。
ほら、ＮＴ乗っけた原潜が事故りそうになった事件があったじゃないですか。
ＰＬ法に限った話（なんせ制御屋は一番コレが怖い）で行くと、事故が起こった場合の責任は「システム設計」に課せられます。
ＯＳを含むソフトはここに入りません。唯一例外と言われるのが ROM に焼いたファームウェアで、これはＰＬ法の対象になります。
だから、ＭＳが BIOS プログラミングにも手を出してたら原潜事件の時ヤバかったかも。
まさかプラントの制御に使うわけじゃないだろう
事務仕事でエクセル、ワードを使う程度じゃないの
注意書きが至る所にある
・日本の某電気カミソリ・メーカー(中小企業で、大手メーカーにOEM供給)が、ドイツの大手の電気カミソリ・メーカーに、米国で知的所有権侵害の民事訴訟を起こされて裁判に負け、巨額の賠償金を支払わされた。
・インドのボパールでガス流出事故が発生して、2000人以上の住民が死亡した大事故で、米国の弁護士が現地に大挙して乗り込んで、被害者から委任状を取りまくって、損害賠償額の高い米国で民事訴訟をおこされて、元経営陣はお尋ね者になった。
・業者に依頼して自宅にプールを作らせた。逆さ飛び込みをしたところ、頭を打って大けが。プールには「飛び込み禁止と、その理由を書いたマニュアルがなかった。」と裁判に。結果は勝訴。プール会社は倒産。
・マクドナルドのフライドポテトで菜食主義者から訴訟を起こされ「フライドポテトに牛脂を使用している表示がなかった」という理由だけで１２億円支払い命令。
・フロリダで化学工場が大爆発する事故があった。事故の様子をテレビで見た地元の人が「精神的なショックを受けた」と化学工場を訴え、その訴訟は成立した。
・職業別電話帳(イエロー・ページ)を見ると、顔写真入りの一面広告を出し、２４時間３６５日、フリー・ダイヤルで受け付けている法律事務所がある
・アフガニスタンで大規模なアルカイダ壊滅作戦を展開、７５０人にのぼる捕虜を捕捉していたら、「収容所での扱いが不当だ！！」で米国政府が米国の裁判所で訴えられた。
・外国で談合していたら大丈夫だろうと思ったら米国子会社が起訴された。
・密室で談合していたらバレないと思ったら、メンバーの１人がおとり捜査官にすり替わっていた。
・事故があると病院に駆けつけたり、救急車の後を追跡して病院に駆けつけたり、病院で待機していたりして、被害者や家族から委任状を取る。
・訴訟費用の全てを法律事務所(弁護士)が負担する代わりに、勝訴した場合には、勝ち取った賠償金の４０パーセントから５０パーセントを 成功報酬として得る成功報酬制弁護士もいる。
・日本の弁護士の人数が日本全体で約１万８０００人であるのに対して、米国の弁護士の人数は米国全体で約８０～１００万人。
これらは全てガチですｗｗ真実ですｗｗ
信頼性が欲しければしっかりしたソース。それが2ちゃんねる。
最近のトヨタ車の集団訴訟騒ぎを忘れた？
http://www.news24.jp/articles/2010/02/03/10152843.html
http://plaza.rakuten.co.jp/mimolove18/diary/201002030000/
http://www.bloomberg.co.jp/apps/news?pid=90920000&sid=aaqxO801w0B4
http://www.afpbb.com/article/economy/2708528/5475665
しかしブルドックは不可
ボパールでガス流出事故に関する集団訴訟は紛れも無く実在する。
実際にインドの事件について米国で集団訴訟がおこされている・・・・。
SAJIDA BANO v. UNION CARBIDE CORPORATION and WARREN ANDERSON
http://www.elaw.org/node/2560
http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=2nd&navby=case&no=009250&exact=1
http://openjurist.org/273/f3d/120/sajida-bano-v-union-carbide-corporation-
Jagarnath Sahu et al v. Union Carbide Corporation et al
http://dockets.justia.com/docket/court-nysdce/case_no-1:2007cv02156/case_id-302312/
http://www.websupp.org/data/SDNY/1:04-cv-08825-23-SDNY.pdf
http://amlawdaily.typepad.com/keenanbhopal.pdf
Sahu v. Union Carbide Corporation
http://www.bhopal.net/pdfs/Sahu%20Opinion%2011.3.08.pdf
http://vlex.com/vid/sahu-v-union-carbide-corporation-43930484
2008.2.7 11:12
【ワシントン＝渡辺浩生】中国産の原料を使ったペットフードを食べたイヌやネコが相次ぎ中毒死した問題で、
米ミズーリ州の連邦大陪審は６日、原料を製造した江蘇省のメーカーなど中国企業２社と
ネバタ州の輸入業者を起訴した。日本では農薬が混入した中国製ギョーザを食べた人が重体に陥るなど、
中国製品の信用が揺らいでいるが、米国で食の安全問題に関係して中国側の関係者に刑事責任が問われるのは異例のことだ。
食品医薬品局（ＦＤＡ）が同日発表したもので、３社の経営者らも同時に起訴された。３社は共謀して、
米国で使用が禁止されている化学物質メラミンを混入した原料を「小麦グルテン」と称して８００トン
（８５万ドル＝約９０００万円相当）を米国に輸入した疑い。中国当局の検査を逃れるため偽の申告もしていた。
メラミンを混ぜると原料のタンパク質含有量を高く見せることができ、製品には「最低含有率７５％」と偽表示されていた。
この原料を使いカナダのメーカーが製造したペットフードで昨年３月以降、イヌやネコが大量に中毒死していたことが発覚した。
中国政府はこれら中国企業２社を営業停止処分にするとともに責任者を逮捕。
このペットフード禍は中国製品への消費者不信が広がる契機となり、その後も、有毒練り歯磨き粉のほか、
抗菌剤が検出された魚介類の輸入禁止、さらには鉛が混入した玩具の大量回収と波及していった。
http://sankei.jp.msn.com/world/america/080207/amr0802071112012-n1.htm
FREE TIBET,
CHINA FREE.
486が出るか出ないかの窓3.xの頃に売り込んできたけど門前払いされてた。
後になってWindowsCEの原型らしいと聞いた。
これを制御しているＣＰＵは・・・・。
68000
http://www.hq.nasa.gov/office/pao/History/computers/Ch4-7.html
http://www.hq.nasa.gov/office/pao/History/computers/Ch4-8.html
8080あたりのような気がしてた。
当初設計の機材が古くなり過ぎたんで作った新型で使ったのが68000。
このまま最期まで68000のままかな。
今のところディスカバリーの38回が一番回数多いのかな？
としてしか使われないことがあったという話を聞いたことがある。
Windowsが普及して使われ始めるまで、それから結構かかっているね。
Windows3.1が発売されたのが１９９３年か。
職場に導入されたPCはMSｰDOSをまずインストールしてそれからWindowsを
インストールしなければならなかった。全部FDだったな。シリアル番号とか何も無し。
LANにつなぐのにLAN Workplaceというソフトを別にインストールしなければ
ならなかった。
それまで使用していたOA用WSはモトローラの68030を積んでいた。WSと違ってPCは
よくハングするし、HDDもよく飛ぶので評判は悪かったが、時代の流れには逆らえなかった。
安定してバグやセキュリティーホールのないOSに果たしてこの先お目にかかれるか？
９８DOSはそれでもハングしたりリセットがかったりした。
主に、ATOKのせいで。
意味わかんないこと言うなよ。
Windows でも Unix でもデバドラにバグあったら簡単に OS ごと吹っ飛ぶだろ。
お前のほうが意味わからんよ。
> DOSに、アプリが保護されるようなモードがあったかよ。
>>480 で「アプリのバグ」なんて書かなきゃ突っ込まれなかったのに…
アホな上に見苦しいやつ。
ないというわけじゃない。
ただ >>480 の文脈だと「意味わかんないこと言うなよ」レベルだが。
その後はWin2KかFreeBSDか
実装次第では暴走したドライバを終了させ、ドライバをリロードした上で
デバイスを再起動・正常化させる事も（実装次第では）可能。
ドライバが別空間で動作しているからと言って、
それだけではデバイスのみを再起動できる保障は無いし、
デバイスの再起動に成功したとしても、それを利用していたアプリケーションがどうなるかは
さらに保障の限りではないわけだが。
システム自体は何事も無く稼動を続け、デスクトップ環境を再起動することは当たり前にできる。
しかしXやDEの再起動に成功したとしても、そこで使っていたアプリケーションは（親プロセスのXと共に）落とされた後の話。
またLinuxやBSD系のようなモノリシックなシステムでは、
GPUのドライバが暴走すれば、カーネルごと巻き込んでシステム全体が落ちる可能性が出てくる。
Windowsでも、XPまでは同様だった。
BSODはWindowsのせいだと思われがちだが、そんな汚名も実態はグラフィックカードのドライバに起因していた
という事をMicrosoftは突き止め、Vista以降では再びドライバをユーザー空間に切り離し、再起動とその後のフォローまで組み込んだ。
Windows 7やVistaでは、グラフィックカードのドライバやシェルのExplorerが暴走・ダウンしたとしても
BSODに直結することはなく、ドライバやシェルプロセスを自動的に再起動させ、デスクトップが復帰する。
>
> お前のほうが意味わからんよ。
DOSに、アプリが保護されるようなモードがあったかよ。
屁理屈はいらんですよ。
> DOSに、アプリが保護されるようなモードがあったかよ。
>>480 で「アプリのバグ」なんて書かなきゃ突っ込まれなかったのに…
アホな上に見苦しいやつ。
kwsk
ReactOSでring1でドライバが動作する機構を用意してくれないかなぁ・・・
◎エンコーダECとレピータRPのCPUは8085
◎車上演算CPUは68000
http://www.geocities.jp/jtqsw192/FIG/320p/atspcd1.htm
http://www.geocities.jp/jtqsw192/geobooks/geobook10.htm
部品も「最新」を追うのではなく、採用後、なるべく長期に安定して入手できるものを選ぶわけで、
要求仕様をきちんと満たせば、それ以上の高性能は無用ということ。
例えば NECのPC-9801の生産打ち切りはJR各社に衝撃を与えています。
あんなに脆く撤退するとは思いませんでしたからね。目先の高性能を追って、
すぐ別のものに切り替えられては困るというわけです。
組み込み用途は「動けばおｋ」の世界だからかなりとんでもないことをしている。
intelがAtomの売り込みに行ったら、「30年後も部品を売ってくれると約束するなら買うよ！！」といわれるぞｗｗ
半導体プロセス丸ごと1個おまえのところのために稼働させ続けるんだから、
1000億とかそういうオーダーになるだろうが。
こういう奴をアホって言うんだろうなぁ
ガ●アックスのアニメじゃあるまいし、試作品をいきなり本番に投入できるかよ｡ 人命と膨大な銭が掛かってるんだぜ？
「バグったら誰か死ぬ」「バグで億単位の大損害」「バグで大都市がパニック！！」が発生する可能性がある分野では
性能二の次、三の次で耐久性や信頼性に冗長性を最優先にたたき出す工夫をしている。
「電子連動Ｉ型」という国鉄時代に開発された鉄道の連動装置ならばCPUとメモリを3個並列に並べて、同じ動作をさせ、出てきたのを
比較回路で多数決処理。1系不良の場合は残る2系で処理を継続しますが、残りが不一致したら出力監視回路を遮断して、リレーを落下。
ウォッチドッグタイマーのしくみも、ＰＣに入っているようなもんじゃ、勝手にタイマーそのもののプログラムがバグ吐きそうで信用できないから
ちゃんとプログラムが正常に動作していないとリレーが落下するようなしくみのやつがついている。
この電子連動装置はCPUが8086を3個内臓でメモリは64KBなのに、なんとダイヤ管理機能まで持たせていた。
ただし、処理性能が大幅に犠牲になっていて進路設定してから信号機に現示が出るまで、
ポイント転換時間を除いて6秒以上かかるという、リレー式より格段に遅い。
しかも、まだ現役バリバリかもしれないらしい・・・。
ARMがヒットしてる一因もこれがある
こういう奴をアホっていうんだよ。
ってのはWindowsにも無いと思うが。
インテルってサッカーチーム持ってたのかと思った
スレチだがサッカーのインテルってIntelと無関係なの？
インテルサットはインテルが作った人工衛星だと思ってた？
誰もbugで苦労しやしないわ。
察してやれよ。
http://news.searchina.ne.jp/disp.cgi?y=2010&d=0701&f=national_0701_003.shtml
http://pc.watch.impress.co.jp/docs/news/event/20090923_317302.html
…心意気だけは…
どんな仕様になるのかいまいち想像がつかない
いっても大したものは残っていない気がするね。
速度的に不満だった部分は68020以降改善されていったし。
しいて言うなら、8bit CPUのプログラムを移植しようと思ったときに、Aレジスタと
Bレジスタを合体させてDレジスタとして使えるみたいな機構があると楽だったと
思ったな。
ついでに奇数アドレスからのワード、ロングワードアクセスが可能だと相当機械的
に移植できるのにと当時は思っていた気がする。
少しは486DXに対抗できたかもしれないと思う
63C09とかCMOS版の68000勝手に作ってトラブルになったんだよ
未来もなかったけど
H16じゃない？
出来上がるのは386より汚いコード体系で386よりレジスタの少ない
ゴミのようなアーキテクチャだと思うよ。
ボッコボコのアーキテクチャだよな。
バイナリ互換とか言っていると、68HC16みたいなバンク切り替えとかセグメント方式
になるから、お得意のソース互換・バイナリ非互換でX/Y/U/S/V/Z/PCを32bitに
拡張する形だろうな。
と考えてきて、既に目の前には68000があるわけだが、拡張版63C09を使う意味って
一体どこにあるんだ？となるだろうな。
レジスタ本数は多いし、命令の直交性は充分だし、大抵の妄想はそこで行き止まり
になると思うよ。
命令長から8bit単位でコンパクトにまとめられる方が現実的には身の丈に合っていた
けど70年代末の時点でそういう製品を作れなかった時点でモトローラの負けは確定していた
80年代半ばくらいまではね。
こんな「とりあえずアーキテクチャ」が30年以上も延命しようとは
夢にも思わなかったインテルは、今プリフィックス地獄にはまって
ボトルネックの悪夢にうなされているね。
PenPro以降でRISCっぽいμopコードに分解して実行するようになったら
むしろコンパクトかつ符号化も完了済みでメモリ効率も高い命令体系となって、
叩いていたRISC陣営が逆に放逐されてしまうという泣き笑い状態だった訳だが
プリフィクス地獄にしたのは、IA32にプリフィクスを置くだけでAMD64とか言っちゃった
どこかの三流メーカーのせいだなあ…これじゃやっとれんって事でIntelはAVXへ。
山のようにトランジスタ投入して鬼のようなワイヤードロジックを力技でねじ伏せるなんて、
とてもあんたの所以外真似できませんわ、と呆れ半分で退散したんだけどな。
そのせいで電力消費は泣き所だし。
IBM PC パーソナル・コンピューティングの発達
ttp://www.ibm.com/ibm100/jp/ja/icons/personalcomputer/
テクノロジーの飛躍的な進歩
ttp://www.ibm.com/ibm100/jp/ja/icons/personalcomputer/breakthroughs/
↑このタイミングで(1980年の後半)、CPUの外部調達を考え始めたIBMのチームに
ザイログやモトローラが積極的に石を売り込めていたら…
世界は変ってたかもしれない。
でもたぶん、8bitバスで内部16bitの‘適当な石’の選択肢が 8088
以外になかったんだと思う。
余談だけど、IBM-PCの型番(5150)が、タイムトラベラー(オカルトw)の
ジョン・タイターの話で出てくるポータブル機 IBM-5100 シリーズの
後継機扱い?なのが面白い(知らなかった)。
普及してほしかったんじゃないかなぁ。
でも市場は互換性の呪縛から逃れられなかった…
前にも他のスレで書いたかもしれないけど、自分はいつもこの話題に関連して
キーボード配列「QWERTY」の件を思い出す。
もっと合理的な配列が20世紀初頭に色々提唱されたらしいけど、けっきょく
欧米のタイピスト(秘書?)市場に受け入れられず、そのまま世界標準に。
最初に‘なんとなく’決めた規格や採用したものが、そのまま市場を形成して
あとで改善しようにもできなくなる例って多いよね。
日本だと交流電源周波数50/60Hz問題とか、鉄道の狭軌/標準軌問題とか
半角バックスラッシュ→￥円マーク問題とか(UTF-8でも新￥コードは
なかなか普及しないらしい(過去のDBシステムとの互換性の関係?)。
ずいぶん横道にそれた年寄りの長文で、すみません
それにAVXが解決するのはSSEnのプリフィックス地獄だけな気がする。
一般のx86命令についてはいまだに改善の方向性を示せてないのでは？
x64なんか、1命令が7バイトとか8バイトなんて珍しくなくなったし、もう
勘弁して欲しい世界。
>勘弁して欲しい世界。
本当にAMDはどうしようもないクズ企業だな。無能しか居ない
ttp://documentation.renesas.com/jpn/products/mpumcu/rjj09b0465_rxsm.pdf
ルネサス・エレ(日立＋三菱＋ＮＥＣの合体技)
RXってCISCだったのか…。63C09の正統進化形？(んな訳はないかw)
プログラミングモデルはどう見ても68000の派生アーキテクチャだけど。
命令の直交性とかを犠牲にして、コードサイズの縮小を狙った感じだな。
まぁ、今時命令の直交性うんぬんとか気にする時代でも無いが。
よう厨房
まだ再生産してたかも。オーダーの単位が数千だがな!、まさに外道
今時5Vデバイスは往生するよ。
ttp://www.cqpub.co.jp/interface/sample/200809/if09_048.pdf
部品買ってハンダ付けもしたけど、すごく熱くなるので物置行き。
つうか、もう３年たつのか… 加齢＝高速忘却マジやばいなw
I/Oマップ領域を触らず、S/Uモード(スタックの見え方)や割込みの違いに無関係で、
$A0～や$F0～ラインの未定義命令ジャンプも使わず、単純に引数を受け取って、
何かローカルな処理(演算とか)をして、$4E75 (RTS)で戻る…
みたいなシンプルな68kバイナリ・コードなら、そのまま ColdFire でも
走ると思うんだけど、これを資産と呼べるかどうかは、用途によると思う。
何せ LED チカチカを実験するだけでも、(物理アドレス)ポート叩くからなぁ…
何か特殊な、高速演算？ライブラリとかの類も ColdFireなら、積和演算レジスタを
使って作り直したほうが速そうだし、そういうパッケージも頒布されていそう。
やっぱり ColdFire では削除されてるっぽい
対する68000は最長5ワード(10バイト)なので、命令長から
来る制限がまずあるはず。
例えば、 MOVE.L #$12345678,$FEDCBA.L みたいに拡張
ワードがずらずら続く命令はNGだったんじゃ？
その他にも、3ワード以内であっても、ソース・ディスティネー
ション共にインデックスアドレッシングを指定するMOVE命令
とか、RISCとして複雑すぎる組み合わせもNGにしてるみたい。
ゴメン、ちゃんと小さい文字で注意書きが書いてありました orz
MOVEの転送元 転送先として使えない場合
(d16, Ay), (d16, PC) (d8, Ax, Xi), (xxx).W, (xxx).L
(d8,Ay,Xi),(d8,PC,Xi),(xxx).W,(xxx).L,#<xxx> (d16,Ax),(d8,Ax,Xi),(xxx).W,(xxx).L
>>575 ABCD命令もちゃんと削除されてたw
ゴメン、ちゃんと小さい文字で注意書きが書いてありました orz
MOVEの転送元 転送先として使えない場合
(d16, Ay), (d16, PC) (d8, Ax, Xi), (xxx).W, (xxx).L
(d8,Ay,Xi),(d8,PC,Xi),(xxx).W,(xxx).L,#<xxx> (d16,Ax),(d8,Ax,Xi),(xxx).W,(xxx).L
>>575 ABCD命令もちゃんと削除されてたw
ttp://retropc.net/x68000/software/develop/as/has060/coldfire.htm
さっきまで辞書片手に、ひぃひい言いながら↓これと格闘してたw
ttp://cache.freescale.com/files/dsp/doc/ref_manual/CFPRM.pdf?fsrch=1&sr=48
ColdFire Family Programmer's Reference Manual (約1.7Mバイト 興味ない人ゴメン)
ttp://cache.freescale.com/files/dsp/doc/ref_manual/CFPRM.pdf
ttp://www.retropc.net/x68000/software/develop/as/has060/has060.htm
hasのマニュアルに、削除命令がある。
DBRA(DBcc)が削除されたのは痛いな。あとEXG
同意
x86がマイクロコード実行パイプを残して対応したような部分を、バッサリ切って捨てたような印象。
まぁ会社としては上位にPowerPCがあって、そっちに注力してた最中だろうから中途半端になる
のは判るけど、そんな68ｋ一部互換に意味があったんだろうかと疑問を感じるね。
名前に反してSuperHOTだったみたいだしw
>>581さんも言ってるDBRAはもちろんだけど、ローテート命令は削除か。
暗号処理とかで泣く場面は無いのかな？
それとADD/SUB/CMPのロングワード限定。
バイト・ワードサイズのデータを比較して、その後Cフラグで分岐とか、
そういうのはEXTか、もしくは上位ゼロ拡張してからやってねってことか・・・
めんどくさ。
そのわりにMOVEMみたく、マイクロコード実行の権化みたいなのは削除
されずに残ったんだな・・・
やっぱり、性質の悪いサブセットを見てる気分だ。
というか040を元に命令を減らしているのか？＞ColdFire
6800に対する6502ぐらい違えばいいのに。
68000で命令中のスケールファクタ部は単純に無視されるので、020以降かどうかのMPUの判別に使えたりも。
どこが違うの?
movepほか、いくつか命令が削除された。
その他分岐予測が新たに付いた。
気にしなかったな。
x86だとローテート命令の移動量がマスクされたと言うのがあったのがバレルシフタの副作用だとか怪しげな話しは聞いたが。
もうどっちもアセンブラでなんか使わねーなー…
幅が15より大きい場合に、実際にそれだけシフトするか、上位桁を
無視するかの違い、だったと思った。
カウンタと1ビットシフタでシフトするか、バレルシフタでシフトするかの違い。
評価基盤やエミュレーションあると思いますが、実機どうしてます？
ブレーキ無い自転車にわざとぶつかって数万～数十万ゆするそうだ。
ローテートやint未満の演算なんかは要らないってことでそ
基本的に整数演算はintに符号拡張して行なわれる
ただし結果が同じになるなら符号拡張しなくてもよい
用意しておくべきだったね。
ISA_Bから追加とか、泥縄もいいところ。
HD63C09でモトローラに怒られたしなかったんじゃない?
（片付けしてたら棚から出てきたw）
確実に判別できるんだけど、いかんせん未定義になってるバイナリ
の数が多すぎるからねぇ。
昔68でHCFっていう伝説の未定義命令があったなー
Halt and Catch Fire
実行するとハードが火を噴くという・・・
オペコードでそれっぽく動作しちゃったりする石はたまにあったよね他にも。
>>615
特定の信号線がローとハイに目一杯切り替わり続けるとかいう奴ねw
ロー側とハイ側のトランジスタが同時にオンになるとかもあったりしたら怖いが。
レジスタとフラグがどう変わるか書き出してた。
モノによっては使えるものもあったな。
それが残ってないってコトは、使えるないようではなかったってことカナ？
確かに。CMOS化後の話？
ttp://ja.wikipedia.org/wiki/MC68882
68040 の浮動小数点演算内蔵化で、三角関数が外されたのが残念
ttp://ja.wikipedia.org/wiki/MC68040
いや単に、MacのIIvx (030採用機)をローンで買った直後に
Mac Centris (040採用機)が発売されて悔しかった自分のグチなんだけどさw
よくあるES(エンジニアリングサンプル)品。 PC68060とかも存在するよ。
ということは PC → XC → MC というような流れで量産が立ち上がっていくのかな？
PC68040はわかりませんが、PC68060を持っている方の話では、かなり高クロックでも動いたらしいですよ。
>>631 適切な突っ込み
>>632 痛い
>>633 Wikipediaのコピペ? 間違ってはいない
>>634以降 とても痛い
「68kシリーズは32bitプロセッサ」と言い切るぐらいのトンチンカン
へー、なぜなのか説明してほしいなあ
>>631 適切な突っ込み
>>632 痛い
>>633 Wikipediaのコピペ? 間違ってはいない
>>634以降 とても痛い
得意げに言われてもなぁ
>>636
なんかアホみたいに wikipedia に反応する奴いるけど、
誰一人それ以上の情報出せない件。
かわいそう…
>>636
なんかアホみたいに wikipedia に反応する奴いるけど、
誰一人それ以上の情報出せない件。
なんか都合が悪かったんかね
>wikipediaを引き写した
え？どのへんでそう思ったの？ｗ
>今になってやっと引き写したことを否定しはじめたか
同じこと言ってる箇所って
>シリーズ初の製品NS32016(当初はNS16032、後に改名)
ってとこだけじゃん。
素人以下なら尚更、Wikipediaみたいな不正確なもん参照して間違いに気付かない
危険性は念頭において、できるだけ一時情報当たったほうがいいんじゃないの？
正)一次情報
そんな仕事、今時はboot loaderがやってくれます
GRUBが、その面倒なのをすべて処理した上で実行してくれるので、
低レベルなプログラムも書き放題
プロテクトモードで書いてしまえば良いのだし、
モニタに相当する処理を1から書くのが面倒だと言うなら
他のメモリ保護やマルチプロセスに対応した32/64bitCPUでも手間は変わらん。
「x86だと、俺様の気分が乗らない(信仰上の理由でIntelを生理的に好かないから)」
くらいの理由だろ、馬鹿馬鹿しい。
68000と互角かそれ以上の性能を発揮するかのような出鱈目な誇大宣伝を
繰り返していた罪深いメーカーだ。
最近ではＡｔｈｌｏｎ64のＡＭＤ相手に劣勢に立たされた時に
札束攻撃で提灯記事を書かせメーカーの抱え込みでＡＭＤのＣＰＵを締め出すなど
政治的対策でライバルを排除し独占禁止法違反に問われていたことも記憶に新しい。
インテルが好かれないとしたら信仰上の理由ではなく、正当な競争を妨げることもある
限りなく黒に近いダークな側面を持った企業だからなのである。
まあパソコンの需要がスマホおよびタブレット端末に食われはじめ
x86自体の独占が崩れつつある今となってはどーでもいい話ではあるが。
>インテルは当時8ビットCPUを無理矢理拡張したアーキティクチャの8086をして
>>68000と互角かそれ以上の性能を発揮するかのような出鱈目な誇大宣伝を
>繰り返していた罪深いメーカーだ。
そんなことあったっけ? ないでしょ。
リニアアドレスだけが取り得で、隅っこで生き長らえていたようだが
スーパーバイザのメモリ空間が完全に分離している設計もありえる
環境耐性が高いだけが取り柄の素人お断りの変態MPU
素人乙
仮想マシン/仮想記憶関係が不完全だったけど、当時だとたいして影響無かったと思う。
この業界出したモン勝ちの傾向あるから、リリース時期は重要だし。
010との違いでいえば、スタックフレームの非互換が痛い。
上とも重なるけど、当時はバイナリの互換性が重要な時代だった。
EEP-ROMはまだなかったよね。
> 歴史 [編集]
> 1978年、インテル社の George Perlegos は初期のEPROM技術に基づいて Intel 2816 を
> 開発したが、酸化膜の層を使い紫外線を使わなくともチップ自身がビットを消去できるように
> した。
どうにかするためにはどうしようもなかったんでは？
ラッパー関数で隠蔽したけどね。
68008用に書いたプログラムをなぁんにも知らない奴がリコンパイルしただけで「割り込みがうごかねぇ！バグだごらぁ」と
部署変わったのに怒鳴り込んできたことがあったっけ・・・
OSとかデバッガーとか書いてる人はちょっと手直しが必要だったけど、
修正量はたいしたことなかったはず。
そもそも、68系使ってる人は元々バイナリの互換性を当てにして無かっ
たと思う、8bit 時代からそういう会社だったし。
X68020
だったらよかたな
今はエミュレータ様々だけど、当時のwktkはもう戻らない。
いま100円で買えるマイコンはまだ8ビットとかそんなだ。そこまで速くはない。
ATと86を始める元気は無いし
（x68本スレ？は変に荒れてるし）お許しを
アレの塊（68＋98の奴）のことなんだけど、ファイルが多くてデカすぎて中身がわからない
とても40g全部いくわけにはいかない
空の不動産・あの素晴しい をもう一度のx68版が
入ってる圧縮ファイルはどれなのか教えて欲しい
エミュでさえウザイのに、その上違法ダウンロードかよ
もうどっかいってよ
FM TOWNS - Wikipedia
http://ja.wikipedia.org/wiki/FM_TOWNS#cite_note-31
> 28. ^ 富士通はかつて8ビットパソコンの時代にもFMシリーズで6800系パソコンの老舗で
> あった日立の独自アーキテクチャのパソコンを消滅に追い込んだ過去を持つ。
おとなしく巣に帰れ。
買った?
なかったか？
薬でもしているのかいな
両方とも伸びなかったからな～。
も１回スレ立てるので、援護射撃たのむぜ。
最初の１週間が肝心だから。
http://www.computerhistory.org/
http://maps.google.co.jp/?ie=UTF8&ll=37.41429,-122.077251&spn=0.002855,0.006207
「インテル 386 マイクロプロセッサのデザインと開発 口述史パネル」
参加者: John Crawford, Gene Hill, Jill Leukhardt, Jan Willem Prak, Jim Slager
司会: Jim Jarrett (386開発陣への回顧インタビュー 2008/12/02録音)
http://archive.computerhistory.org/resources/access/text/Oral_History/102702019.05.01.acc.pdf
(別スレで依頼があったので、面白そうな所を適当に抜粋・意訳。英語は苦手なほう
なので日本語が変だったり、誤訳があったらすみません。p4 の中盤あたりから)
[Jill Leukhardt:] We were not cognizant of the importance of software that
was being developed for the PC and its user base, so what is obvious today
in terms of the installed base of software and the vast importance of that
compatibility was not at all obvious when we were entering into the definition
phase for the 386.
私達はPCユーザーベースで開発されたソフトの重要性を認識していませんでした。
インストールベースのソフトの見地では互換性の重要さは、現在では当たり前ですが
386の設計段階に入った当初はまったく明白ではありませんでした。
In terms of the competitive environment, the Motorola 68000 was a superior
machine, and we knew it and felt it very strongly. We perceived that we were
going to be later than the 68020, the Motorola 32-bit product that we would
be later to market with the 386 and so we felt that very strongly and that
created a real sense of urgency in terms of what we were trying to do.
競合他社としてモトローラの68000が優れていることを私達は強く感じていました。
さらにモトローラの32bit製品、68020にも遅れをとっていると認めてました。これは
386が後から市場に参入することになるので、私達も本当に緊急性を強く意識していました。
reviled; everybody hated 64K-byte segments. They limited the size of data
structures and that was perceived to be and was actually a limitation in
certain applications. Programmers in particular and compiler writers and
others just saw that as a huge limitation. Jim you want to say something?
第三の点は、8086のセグメント方式で行き詰っていたことです。激しくののしられ
誰もが64Kバイトのセグメントを嫌っていました。データ構造の大きさに限界があると
理解され、実際にいくつのアプリでは制限がありました。プログラマー、とくに
コンパイラの作者はこれが大きい制限だとみなしました。Jim, 何か言いたいかい?
[Jim Slager:] Oh yes it’s just humorous when you look back…that we thought
it was so important to have a segment-based memory management scheme because
of the Zilog MMU and it was defined into the 286 and we just thought it’d be
the greatest thing in the world but customers just didn’t agree, I don’t
know what was wrong with them <laughter.>.
ああ、はい。振り返ってみると滑稽な話ですが、当時ザイログのMMUにならって
(訳註 Z8001用のZ8010のこと?) 私達はセグメント型のメモリ管理方式がとても
重要だと考えていました。そして286の設計にも組み込んで、これで世界一偉大に
なるだろうと思ったのですが、顧客層はそっぽを向いたのです。彼らは何が
気に入らなかったのか私にはわかりませんね(笑)。
nobody particularly wild about it, but it’s moving along and now a new effort
is beginning to develop: a follow on to the 286, and that’s where you all
come together. What was the environment within Intel at that point and the
thinking about this new chip?
では1982年の初めに286を世に出して、誰も特に熱狂はしなかったがそれは続き
今度は286の後継機を新たに開発するために皆さんが集められたわけですね。その時点
で新チップに関するインテル内部の方針や環境(雰囲気?)はどうだったのでしょう?
(p5)
[Gene Hill:] Well actually that chip started as a non-chip; the 286 was so
unsuccessful, Bill Gates called it “Brain Dead”. IBM said there could not
be a follow-on; it was a dead-end architecture.
実際はチップ以前のスタートでしたね。286はとても不成功で、
ビル・ゲーツは「脳死」と呼びました。IBMは、後継機はあり得ない、
行き詰まりのアーキテクチャだ、と言いました。
processor that Intel was thinking of bringing out?
286の後継が不可能とすると、次期プロセッサとしてインテルは何を考えていたのでしょうか?
[Crawford:] This was all in the shadow of the 432 microprocessor development
at the time. The 432 was a very ambitious project that Intel was very firmly
committed to and unfortunately it was also late and had slipped pretty
significantly; so we had a number of gap fillers that were thrown into the breach.
That was a little before my time, but my understanding is the 8086 microprocessor
was the first of those gap fillers, followed by the 8088, the 186 and the 286.
That’s another key piece of information here: the 432 project was really
supposed to be our big thrust in the microprocessor market and these other
efforts were really more or less gap fillers.
すべて当時 432マイクロプロセッサ計画が影を落していました。432はインテルが強く
進めていたとても野心的なプロジェクトですが、残念ながらこれも遅れてかなり時期を
逸しました。したがってそれを埋め合わせる‘場つなぎ’がたくさんありました。
私の担当より少し前の話ですが、私の理解では8086が最初に投入された場つなぎの製品
であり、それは186そして286と続きます。ここで鍵となるのは、432プロジェクトが、
マイクロプロセッサ市場でインテルの大きな推進力になると本当に思われていたので
それ以外の努力はみな多かれ少なかれ、場つなぎだったのです。
because there were a lot of people who realized the 432 was fatally flawed.
So the project I joined originally was code-named the P4 and it was a whole
new architecture that was very VAX-like. It was developed by Glen Meyers and
the people in Oregon who had been responsible for the 432 wanted to try again.
A number of them realized there were problems, so they wanted to do it over
basically. So they had a proposal and as Gene indicated the 386, 32 bit
follow-on was kind of the step child already in that discussion.
多くの人が432は致命的に欠陥だらけと考えていたので様々な新アーキチクチャの提案が
ありました。私が前に参加していたのはP4というコード名のVAXライクな計画でした。
432の責任をやり直したがっていた、オレゴンのGlen Meyers達の開発です。たくさんの
人が問題を認識していて基本から作ろうと提案していたので、Geneにとって後継32bit
の386は既に‘まま子’のような扱いでした。
(p6)
[Jarrett:] So this 386 effort was launched and I guess the first thing we need
to talk about is the definition of it. I guess Jill and John you were quite
involved in that process; tell us about it.
さて386の取組みが開始されたわけですが、その設計定義の話を最初に伺いましょう。
JillとJohnがそのプロセスで大きくかかわっていたと思います、お聞かせください。
before Jill, just a few months before and there actually were two architects
on the 386. There was the effort that Gene talked about earlier that Bob Childs
had pulled together. It was a proposal for a 32-bit extension of the 286 and
Glen Meyers had asked me to step in and do one, and so we had these two
sketches of what an extension might be. So we had kind of the battle of the
architectures going on a little bit.
設計が始まりました、私はJillよりほんの少し、数ヶ月前からですが、実は386には二人の
設計者がいました。先ほどGeneの話にあった取組みは Bob Childs が主導していたのです。
それは286を32bitに拡張する提案で、Glen Meyersは私にその一つに入るように指示し
拡張がどうあるべきかを、二つのスケッチ(方針)で社内競争させるようなものでした。
George Alexy was the Marketing Manager and he took Bob Childs and me out to
seven selected customers to bounce both sketches off of the potential
customers and get feedback from them.
営業マネージャのGeorge Alexyが7つの潜在的な顧客を選び、Bob Childsと私をそこに
引き合わせてフィードバック意見を聞きました。
[Jarrett:] So what were the key differences between the two approaches:
yours and Childs?
あなたのとChildsのと二つのアプローチのおもな違いは何だったのでしょう?
[Crawford:] My proposal was a simpler upgrade and I think kind of the essence
of it was to focus on the key issues, which were to extend the address space
to 32 bits and in particular provide a flat addressing of 32 bits.
That was a key failure or lack in the 286 that I think was mentioned earlier.
私のほうがシンプルな提案で、32bitのフラットなアドレスにおもな重点をおいてました。
先ほど指摘したようにそれが286の失敗の鍵・欠けていることだったので。
Second thing was to make it a full 32 bit machine so have some way of giving
it a full 32 bit instruction set.
The other thing that we wanted to fix was to increase the number of registers.
The proposal I put forward was a more minimal extension and admittedly it
fixed two of the three issues. It provided the flat 32 bit addressing.
It supplied a full 32 bit instruction set.
It did not change the number of registers. The proposal and the instruction
set looked-- the instruction setting coding was very similar to the 8086.
So the instruction decode piece would have been a small change or a much
smaller change.
二番目として、フル32bit機つまり完全な32bit命令を何か実装する方法です。
その他にはレジスタの数を増やしたいこともありました。私の提案する方式は
そのうち二つだけを直しました。フラットな32bitアドレスとフル32bit命令です。
レジスタ数は変えませんでした。命令セットは8086によく似ているのでデコーダも
より少ない変更ですむだろうと思われました。
Child’s proposal on the other hand tried to address all three and in doing
so he ended up with a much more complicated instruction encoding strategy.
In particular the 32 bit instruction set was quite different from the 16 bit
instruction encoding. It did provide the opportunity though to increase the
number of registers, which addressed the third point.
Today I can’t remember how well it did on the first two but he did have the
distinguishing factor that it increased the number of registers.
いっぽうChildsの提案方式は(前述の)三点すべてを直そうとする試みで、もっと複雑な
命令エンコード戦略でした。特に32bit命令セットは16bit版とかなり違っていましたが
レジスタの数を増やす機会が得られました。
最初の二点を彼がどううまくこなしたか、今となっては思い出せないのですが
レジスタ数を増やすという三番目の点が、はっきり私のと違っていました。
顧客の意見はあなたのアプローチを選んだ… ということで正しいですか?
[Crawford:] Well I think we got mixed feedback from the customers.
There were some customers that didn’t care at all about 8086 compatibility.
We wanted to see a broad range of customers, some of whom weren’t even using
our products, so clearly they wouldn’t care much about the compatibility.
Others were quite concerned about it, but I think overall the feedback was
compatibility would be nice to have but not critical, and that is kind of
curious looking backwards.
On the other hand, our field application engineers gave us very strong
feedback that we had to run the old software, and that would be critical for
success of the project and also critical for continued success of the 286
and the other products.
賛否とりまぜたフィードバックだったと思います。8086との互換性を全く気にしない
顧客もいました。幅広い分野から聞いたので、中には私達の製品をまだ使っていない
のもあり、明らかに互換性はどうでも良かったのでしょう。他の顧客では、互換性を
とても気にする意見もありましたが、全体としては「互換性はあれば望ましいが
クリティカルではない」という感じでした。思い返してみると奇妙ですね。
いっぽうその逆に、社内の現場アプリ技師達は、古いソフトを動かさねばならないので
互換性が極めて重要だと私達に強く主張しました。そしてこれがプロジェクトの成功や
286その他の製品の持続的な成功にとってクリティカルなのだと。
彼らが懸念していたのは、PCソフトウェアの互換性だったのでしょうか?
[Crawford:] Oh no, not at the time, I think it wasn’t that long since August of
1981 with the big IBM PC introduction. It seemed that the PC was an interesting
design but not one viewed as really the key thing to win and to do well on.
Instead there was still a broad range of designs from the terminals to kind of
little minicomputers to the personal computers which were just emerging.
いえ、あの頃は違います。大いなるIBM PCが発表された1981年の秋からさほど経って
なかったと思います。PCは興味深いデザインではあるが、後に善戦・勝利の鍵となる
ものだとは、みなされてませんでした。その代りにまだ、ターミナルから小規模ミニコン
や始まったばかりのパーソナルコンピュータに至るまで、広いデザイン(分野)がありました。
be a market to focus on?
ワークステーションはどうでしょう? これについて、市場の焦点として考慮しましたか?
[Leukhardt:] Well we thought that was a key market segment for the 386.
It was not a market segment where the 286 was doing well at all;
it was a market segment where the 68000 was cleaning up principally because
the 286 was not viewed as a machine that ran Unix well and the 68000 was viewed
as a natural Unix machine. So when we were working on the 386 definition we
wanted it to have as one of its attributes being able to run Unix well.
So that’s one of the things that influenced us in terms of wanting to have a
way to run the 386 as a flat 32-bit machine, and that’s one of the things
that led to all the angst in the definition process about compatibility versus
a flat 32bit machine and how they would coexist.
ええ、386の主な市場分野として考えていました。286は全くだめでした。主として
68000が総ざらえしている分野でした。なぜなら286はUnixをあまり良く動かせず、
68000は自然なUnixマシンとみなされていたからです。なので386の設計を開始したとき
私達はUnixが良く走るという特性を持たせたかったのです。これはフラットな32bit機
として386を動かしたいという点に影響します。したがって、互換性とフラットな32bit
マシンの共存をどうするかが、設計プロセスのすべての苦悩のひとつでした。
how did you address that?
アーキテクチャ的に挑戦すべき鍵となる点が形作られたわけですが、どう取扱いましたか?
(p8)
[Crawford:] In fact that was one of the most difficult architectural issues
that I had to wrestle with: how to keep that compatibility with the
segmentation yet provide this thing and I know we went through endless
iterations and had a lot of advice from many people.
In the end the thing that worked was inventing a fictional address space in
between the programmer’s virtual address space and the physical address that
you go to memory with; in fact we had to invent a new name for it,
so we called it the “linear address space”
We kept the segments but we provided the ability to have a segment that was
four gigabytes in size and that let the workstation guys and the Unix people
address this four gigabyte flat address space basically by setting up one
segment and having all of their programming objects within that one segment.
実際、私が取組まなければならなかった中で、最も難しいアーキテクチャ上の問題でした。
いかにしてセグメントの互換性を維持しつつ新機能も提供するか、繰返し際限なく
多くの人から助言をもらいました。結局、プログラマーの仮想アドレスと物理的な記録
アドレスとの間に、架空のアドレス空間を創案することで対応しました。実際、
「リニア・アドレス空間」という新しい名前を考案しました。
機能はそのままサイズが4ギガバイトのセグメントを持てるようにし、ワークステーション
やUnixの人は、このセグメントを一個だけ用意して、全てのオブジェクトをその中に
いれれば、基本的には4ギガのフラットな空間をアドレスできるわけです。
it’s incredible and one thing that I remember well is that the architect of
the 8086, one of the two architects, Steve Morris, who started the whole X86
phenomenon… he was bitterly opposed to the segmentation model that was
installed in the 286. When the 386 turn came he was very active-- he was still
at Intel in software somewhere-- and he was very much opposed to the segmentation
model because of the two-part pointers. In fact he called it software poison.
もちろん、知っての通りこれら全部について議論はありました。私がよく覚えてるのは
8086を設計した二人の開発者のうちの一人、Steve Morris つまりx86現象を始めた張本人
である彼が、286に組み込まれたセグメンテーション・モデルに厳しく反対したことです。
彼はソフトウェアか何かの部門でまだインテルに在籍してましたが、386の段階が来ても
とても積極的で、ポインタが2パートになるという理由で、セグメンテーションにとても
反対でした。実際彼はそれを、ソフトの害毒と呼んでました。
This was the environment that John had to work in and he did come up with a
brilliant solution. We ultimately ended up with the best of all worlds: we had
the compatability, but that whole segmentation model which was pretty much
generally hated could just move over to the side and not interfere with the
software.
It still had to be there, we had to design it in and test it and that was pretty
bad, but it could get out of the way and not prevent the success of the 386.
こういう環境の中でJohnは仕事に取組み見事な解決策をもたらしました。究極的には
全世界で最善の形で仕上げました。私達は互換性を維持しましたが、一般的にかなり
嫌われていたセグメントモデルは、ソフトに干渉しないように脇にどけることができます。
それはそのまま残し、設計上もテストも大変でしたが、そこから抜け出すことができ
386の成功の障害にはなりませんでした。
to the solution that included segmentation plus a flat address space, sort of
the “have it your way” approach after we made the decision that we had to
build a fully compatible machine that is an object code compatible 386, and
that took a long time to decide. In retrospect that seems like a completely
obvious decision but we wrestled with that decision for months and it was a
tough decision-making process.
オブジェクトコード完全互換として386を作らねばならないと決めた後に、セグメントと
フラットアドレスの両方を含み、いわば「あなたの好きな方法でどうぞ」のアプローチを
とる解決策を得て、やっと私達は前を向くことになります(?)。この決断には長い時間が
かかりました。思い返してみるとまったく明白な決断に思えるのですが、当時の私達には
何ヶ月も要する大変な意思決定プロセスでした。
both segmentation and paging. Was there any kind of a performance price that
you paid as a result of this?
そうして John, あなたはセグメントとページングを両方内蔵する新しいアプローチに
辿り着いたわけですが、その結果、何かパフォーマンスの劣化がありませんでしたか?
[Crawford:] That’s an interesting question; in fact it was obviously a big
concern because we were putting in two translation steps.
Of course it’s a critical path on any computer, and that was a big concern
all through the internals of the chip and even the BUS definition that was a
careful concern. But the advantage was, I think it was mentioned before, we
got the best of both worlds: we had segments for compatibility and paging for
a flat address base; that was pretty much everybody.
いい質問です。実際、二段階の変換ステップを入れるは明らかに心配でした。もちろん
どんなコンピュータにもクリティカルパスはあり、内部だけでなくBUS設計でも注意深さ
が必要な懸念材料です。しかし利点が(勝って)いました。先ほど言ったように、両方の
良い所を得られます。セグメント互換性とフラットアドレスベース用のページングです。
これは皆にとってちょっとしたものです。
there some debate on this approach?
社内的には全員がすぐに賛成したのですか、それともこの方法に何か議論がありましたか?
[Crawford:] Well, I think that came at some point in 1982, but before that
there were many proposals, obviously which didn’t survive, that didn’t solve
the problem as completely. At some point there was a decision taken to go with
my architecture as opposed to the Bob Childs architecture. As I remember, a key
part of that was involved the software compatibility question and how efficiently
we needed to run old software, and whether there would be a mode bit and
basically have two machines in one or something more tightly integrated.
ええ、これは1982年のどこかだと思いますが、それ以前は多くの提案がありました。
明らかにどれも生き残りませんでした。完全には問題を解決できなかったからです。
ある時点で Bob Childsのアーキテクチャでなく、私の案で行く決定がなされました。
私の記憶では鍵となる要素には、互換性の問題や古いソフトをどの程度効率よく動かす
必要があるか、モード・ビットを使って基本的に二種のマシンを入れるのか、それとも
より緊密に統合するのか、という点を含んでました。
I think for reasons of simplicity and for efficiency and time pressure we opted
for the simpler model, which is the one that I had proposed that gave us the
32-bit extensions but without having a mode bit and without having a huge
difference in the instruction sets. As I mentioned earlier, the price for that
was we kept the eight-register model which was a drawback of the X86, but not a major one.
簡便さや効率性や時間的なプレッシャーが、モードビットなしで命令セットの大きな
違いのないシンプルな私の案を選んだ理由だったと、私は思います。先ほど話したように
代償はレジスタ8個のモデルで、x86の欠点が残りましたが、大きな問題ではありません。
I guess in addition I got half credit for the register extension because I was
able to generalize the registers. On the 8086 they were quite specialized and
the software people hated that too. One of the things I was able to get into
the architecture was to allow any register to be used to address memory as a
base or an index register, and was even able to squeeze in a scale factor for
the index.
さらに、レジスタを汎用化できたことで半分は面目を保てたと思います。8086では
とても特殊化されていて、これもソフトウェアの人々から嫌われていました。
私がアーキテクチャに組み込めたことの一つは、どのレジスタもアドレスのベースや
インデックスとして使え、さらにスケールファクタも入れられる点です。
【8bit機】CRTC,VDP,ALU,メモリマップ,MMU 専スレ
http://www.logsoku.com/r/i4004/1221375066/290-
からの話題で、一部だけ紹介のつもりだったけど、大長文になってしまいすみません
突っ込み、おかしい点のフォローなど、よろしく
楽しく読ませてもらいました