さてさて、ついに最終講義と相成りました。

と言っても、今回の内容は単に最後にたらたらと何か言うだけで、特別な意味は何も含まれてはいませんし、まぁ読んだ所で何かいい事があるというわけでもありません。

またProgramも今回は一切掲載されていませんので、ある意味、全くの無意味な講義内容かもしれませんが、御付き合いくださいな。

まぁ、ここまでこうして色々と説明らしからぬ事を企んで進めてきたつもりだったのですが、実際にこれらを読まれて、どう思われたかは私には到底わからない事ではありますが、これら講義内容が少しでも、これからの皆さんにとっての一助となれれば幸いであるという事は前回の末尾でも申しましたが、事実、一助となるかどうかも危ういとさえ思ってます(^^;

といいますのも、殆ど私の組んだProgramを見せただけで、実際の内容についてはあまり深く説明していなかったからです。

まぁ説明するにしても、どう説明すべきかというのも問題ではありますが、寧ろ説明すべき内容がやや抽象的で、やり辛かったというのもあります。

それだけでなく、私がやや筆無精・文章下手という、モノ書きにとっては致命的な欠点を合わせもっているものですから、こうなったのでしょう。

まぁ精々いえる事は・・・Source Listは全部公開したから、あとは必要に応じて各人で解析・理解してみてねっていうぐらいでしょうか（無責任ですが(^^;;;）。

というよりかは、寧ろ今回掲載した内容が理解できるようになれば、ほぼ初期の段階は完全に達成できるようになったと判断していいのではないのでしょうか（というより、完全に理解できるような事があったら、初期どころかかなりの上級かもしれませんが）。

と言いますのも、Assemble Programというのは各自の書き方・作り方というのがあり、ある程度の定石があるものの、それは極一部にすぎず、殆どがやはり各自の個性となってしまいます。

私の書き方もどちらかといえば、古典的な書き方ではないと思います。

各Subroutine（Procedure）をどの程度まで厳密化・細分化していき、いかにMain Routineを簡素化しきれるかが、Programの秘訣・・・っていう方もたまにいらっしゃいますが、私もどちらかというと、そういう立場の人です。

しかし、その組み方は昔ながらの（古典的）組み方ではなく、また組み込み型Program向けのやり方でもありません。どちらかというと、ある程度の余裕のある環境向けの組み方です。まぁこうしているのは、単にDebugがしやすいというだけの理由でしかないのですが・・・。

しかし、Bugが少ないというのはとても重要な事です。

まず、Bugの極力発生していないものをつくり、それを用途に応じてCustomizeしていくというのが、特にゼロからの開発を行う際には、最も重要な事だと思うのです。

私も昔はHand Assemblingや1 Line Assemblerを使用した事はあります。

そういった際には、「如何に最適化しきれるのか」が常に頭をよぎった覚えがあります。

が、現在では一般のAssemblerによって、EditorでSourceを打てるような状態になり、徐々に「如何に組めるか」だけしか考えないようになってきてしまったのは事実です。

まぁ、これはDebugのしやすさを求め始めた結果ではあるのですが（かなり大がかりのSourceを書く事もしばしばありますから）。

昔に比べて「最適化」の度合いはやや落ちた可能性はあります。

しかし、過去に最適化を求めた経験があるかどうかはとても重要だと思います。

Assemblerで組む時はやはり「最適化できるから」というのが最大の目標だと思います。この目標知らずして、ただ単にたらたらと長いSourceをかける現在の環境は、どこか腑に落ちない時があります。

更に言えば、C言語やPascalなどのような書けば書く程、実際にCompileした結果がどれだけ冗長があり、最適化すべきものになっているのかが想像がつかないような言語は実の所、あまり好きではありません（実際に逆Assemblingすると、かなり長いSourceになる事が大抵ですし）。

そういった時に、「古典的知識の重要性」というのがやはり明確になると思うのです。つまり、下手にCompiler (Type) Languageを使用するよりかは、Assemblerの方がより処理が明確となり、簡素化しやすいのではないのかと。

だからこそ、私は今回の一連の講義ではすべてAssemblerを用いたものを取り上げたわけです。

まぁたしかに、あまり古典的知識にのっとったものではありませんでしたが、しかし、逆にこれらを読んで「ここはこうしたらどうか」とか「こうしたらより簡素化できるのでは」と気づけるようになれば、それだけで十分な成長だと思います。

私は頭書の蘊蓄でAssembler Programmerの事を「古典プログラマ」と称し、わざわざ「古典」の名を冠していますが、これは敬意の表れであって、下評したものではありません。まぁ敬意の意味である事は、ここまで読まれれば、おのずとおわかりの事とは思いますが。

知識というものは、過去からの積み重ねによって生まれるものです。

確かにAssemblerというものは大抵の方は「過去の産物」扱いしていますが、私はそうは思っていません。

寧ろ「縁の下の力持ち」というべきでしょう。

何にしろ、どういった場合においても、現在の体系をとるComputerでは最終的にはAssemblerというものが必要になってしまいます（各種機器制御や、組み込み動作など）。

それを蔑むなんて事は私にはできません。

そう言った意味でも、私は意味でもAssemblerを使い続けています。

絶対数はどうかはわかりませんが、相対的に見た数は激減したみたいですが、これからも恐らくAssembler Programmerはいなくならないでしょうし、これからも新たにやりはじめる方もいらっしゃる事でしょう。

まぁ、この講義内容が果たしてそういった方々に似合うのかどうかは定かではありませんが(^^;

好くなからずとも、私はAssemblerを使う時に心掛けている事は「あまりにも高度な命令は使用しない」という事に尽きます。

PentiumなどのProcesserではかなりの高度な命令を内臓していますが、私はそれらは一切使うつもりはありません。

そういったものは、自身の手で作り、Macro化するか、Library化すればいいだけの事だと思います。

たしかに、Single Processer上で実現されている場合、処理速度は高速になりますが、その反面、Programmerの性能が劣悪になるだけだと思うのです。

開発者というものは常に頭を働かさなければならないものですから、そういった「作れる（筈の）ものまで楽（手抜き）をする」のは嫌です。だからこそ、8086程度のものでも、使わない命令が多々あります。

実際にはZ80程度の命令数でも十分に事足ります。

いや、RISCのようなものでも問題はありません。

全てはそこから初まると考えるべきかもしれません。

まぁ、私はSISCでしかやっていませんので、SISC的考え方しかできないのですが、極力RISCにも移行できるようにあるべきだと思っています（私の考える「古典」というのは、こういったRISCにも対応できる人を指したりします）。

本講義中でも、高度な命令としては、精々movsやstos程度のなものでしかなかったのではないのかと思います。

これらは、使えば便利で、且つその動作内容も特にややこしいものではないから常用しています。これぐらいのどちらかと言えば底辺に近いものは受け入れる方なのですが、他にも色々とある高度な命令（DAAとかEnterとか・・・）は使う気がしません。やはりこれらは内容は理解できても、その処理がやや複雑なものであるからです。

複雑化したものをひとまとめにして、高速化している事は大いに結構なことなのですが、私は極力「単純な命令で複雑なものを」を目指したいと思っていますし、そうでなければRISCへの移行もできないと思っています。ですから、そういった命令を導入する事には反対しています。まぁ私が反対した所で無意味ではありますが(^^;

と、最後の蘊蓄という事でたらたらと半分「愚痴」のような結果となってしまいましたが、私の考えるProgrammerというのは「自身で新しいものを求める」事にあると思います。

私自身は、一般に呼ばれる「情報工学」というものは「情報分野」と個人的には称していますが（殆ど蔑む意味でです）、それは「人の作ったものの枠組みの中で、パズルをして遊んでいるだけ」だからです。それが殆どに思えるからです。

ただ、Assemblerというのは、どちらかというと、その枠組みの中にあることは同じでも、目標の実現の方法がどちらかというと、「新しい道の開拓」に近いものがあると思います。Compiler型では為し得ないものがあると思います。

やるなら根底をみすえなければならないでしょう。Compiler型言語ではそれはできません。表面をなでられても、絶対に無理な事です。断言できます。それに対してAssemblerではComputerの根底を見なければ全く作業が進みません。たしかに、Computerという人の作った枠組みの中ではありますが、少しだけ、その枠から外れられ易いような気がして、更に言えば「新しい世界」に「すぐに辿りつける」ような気がするからこそ、私自身が蔑むようなこの「情報分野」の中でも、「Assembler」だけは受け入れられたのかも知れません。

・・・っと話がそれてしまいましたが、取り敢えず、私はAssemblerで作るのが今は好きだというだけです。

まぁただのひとりよがりですね(^^;;;

というわけで、最後の蘊蓄はこの程度にしたいと思います。

Assemblerで組むという事自体、大変な事ではありますが、その大変さは「作業行程の大変さ」だけでなく「使命」じみたものがある「大変さ」があるのではないのかと思います。

  「Computerに於いて、Assemblerで実現できない事はない」

それは確かに間違いではありませんが、必ずしもそうではない（実際に作るにはあまりに行程が長すぎて、手をつけられない事だってあります）というのも事実です。

しかし、だからと言って、放棄するのもなんだか悔しいものがあります。

だから、その悔しさに打ち勝つだけの、またその悔しさをバネにできるだけの「使命感」の大切ではないのか・・・と勝手に思っていたりするわけです。

長々と乱文・駄文ではありましたが、ここまでお読み頂き、まことに有難うございました。

今後こういった機会を持つ事があるかどうかはわかりませんが、その際にはまたお相手していただけるよう、御願い致します。