1980年3月には、私を含む新入社員の派遣先が決まった。

 

私の派遣先は三菱電機の鎌倉工場だった。鎌倉製作所と呼んだ方がいいのかも。

 

大船駅から湘南モノレールで2駅目の湘南町屋が最寄り駅で、4月から勤務になるが、その前の3月中に既に三菱電機で派遣の仕事をしている先輩達からの技術講習が一か月近くの期間にわたって開かれた。

 

場所は渋谷駅から歩いていける青山学院大学の教室で、春休みで空いている教室を借りたのだろう。

 

また3月中には会社の寮に移った。武蔵小杉からバスで数分の等々力グラウンドの近くにあった古い木造二階建ての建物で、3月下旬の大学の卒業式にはこの寮から行った。

 

最近、武蔵小杉は高層マンションが林立して人口が急激に増え駅が混雑していると聞くが、当時は駅周辺以外は高い建物もなく閑静な住宅地という感じだった。

 

その技術講習で、三菱電機の産業用コンピュータの概要を知ることになる。勿論、その中にはそのコンピュータのアセンブラ言語も含まれていた。

 

なかなか興味深い内容なので、その技術内容を紹介しよう。

 

当時、三菱電機の産業用コンピュータは確かUNIVAC系の流れをくむコンピュータで、演算や比較を高速で行うアキュムレータを持ちバイト単位ではなくワード単位でアドレスがふられているワードマシンだった。アドレスは最大16ビットまで16進数で書くと0000hから0FFFFh。1ワード=2バイト=16ビットだから最大128kバイトまでメモリを実装できる。

 

また三菱電機の産業用コンピュータはスタックを使っていなかった。

 

リングバッファはFirstIn-FirstOut形式だが、スタックはFirstIn-LastOut形式のバッファで、主に関数もしくはサブルーチン呼び出しやローカル変数用のメモリとして使用される。

 

例えば、C言語記法で void subFunction(int para1, int para2) という関数もしくはサブルーチンを呼び出す際、アセンブラ言語では汎用レジスタのreg1にpara1を設定し汎用レジスタのreg2にpara2を設定した後に、以下のように記述する。

 

    …

    push    reg2

    push    reg1

    call    subFunction

    pop     reg1

    pop     reg2

    …

 

push reg2はスタックにreg2の内容を積む命令で、pop reg1はスタックに積まれた内容をreg1に戻す命令となる。汎用レジスタreg1とreg2のサイズが16ビットだとすると両方とも1ワード単位でスタックを操作することになる。call subFunctionはsunFunctionの戻りアドレス(ここではpop reg1の先頭アドレス)をスタックに積んだ後、sunFunctionの先頭にジャンプする。

 

subFunctionの中ではスタックに積まれたpara1とpara2のデータを取り出して処理した後、retでスタックの戻りアドレス(pop reg1の先頭アドレス)へリターンする。

 

勿論、これはスタックを使用した場合の関数もしくはサブルーチン呼び出しだが、スタックを使用しない場合はどうなるかというと、

 

    …

    call    subFunction

    dw      para1

    dw      para2

    …

 

dwはワード単位でメモリを確保する命令で、para1とpara2に実際に使用する数値を設定してもいいし、その直前にプログラムで値を決めてこのdw領域にセーブしてもいい。

 

スタックを使用しない場合のsubFunctionの動作は、汎用レジスタの1つに戻りアドレス(ここではdw para1の先頭アドレス)が設定されているので、その汎用レジスタの値をアドレスとして使ってpara1を取り出し、次にその汎用レジスタの値に1を加えてdw para2の先頭アドレスを作成しそのアドレスからpara2を取り出す。そして処理を行い、最後にその汎用レジスタの値に2を加えて、dw para2の次の命令…のアドレスを得てそのアドレスを指定してretして、その続きから実行を再開する。

 

スタックを使用する場合と使用しない場合のアセンブラ言語での関数もしくはサブルーチンの呼び出し方の違いが理解できたでしょうか?

 

スタックを使用し関数もしくはサブルーチンの内部ではスタック上のローカル変数しかアクセスしない仕様とすれば、LISPでよく使われるリエントラント(再入可能)なプログラムが実装できて便利なのだが、スタック上のローカル変数は頻繁に書き換えられるので後で動作を追いにくいという欠点があるし、スタックオーバフローの可能性もついてまわる。

 

その点、スタックを使用しない場合は作業メモリの内容が残っているので、メモリダンプを取ればそれまでのプログラムの動作が追いやすい。デッドロックを含めてデバッグしやすいという点でスタックを使用しない利点があったのでしょう。

 

3月の技術講習ではアセンブラ言語の他にアドレス操作機能を加えたFORTRANの紹介もあったが、そちらは比較的短時間でアセンブラ言語に比重が置かれていた。またパッチエリアの必要性も説明された。

 

パッチエリアとはブログラムの先頭に数十ワードのゼロクリアされた領域を確保しておくもので、アセンブラやコンパイラを含まない小規模な産業用コンピュータでデバッグする際に使用するメモリエリアです。

 

そのデバッグ方法では、まず問題があると思われる箇所のアセンブラ言語の命令をジャンプ命令に置き換えてパッチエリアの最初にジャンプさせる。パッチエリアでは修正すべきアセンブラ言語の命令をデバッグに必要な命令数分設定して、最後にもとのプログラムの置き換えるべき命令群の直後に戻るようにジャンプ命令を設定する。ジャンプ命令を含めて置き換えるべきアセンブラ言語の命令はオペコードとオペランドともにハンドアセンブルして16進数に変換して入力する必要があるので、各アセンブラ言語の命令が16進数の機械語にどう変換されるかも理解しておく必要がある。

 

アセンブラ言語とその機械語に習熟するとともにそれらを変換しあえるように最初から求められており、その為の技術講習だった。

 

つまり私の場合は、最初にIBMシステム370のアセンブラ言語を教わり、次に三菱の産業用コンピュータのアセンブラ言語を教わったわけで、もともと私はアセンブラ言語プログラマーなのです。

 

言うまでもなく、以上は1970年代のコンピュータ技術です。

 

ついでに1970年代のコンピュータ技術がどのようなものか追加で説明しましょう。

 

プログラマーがコーディングシートにプログラムを記入してキーパンチャーにキーパンチ依頼を行い、出来上がった紙カードを受け取ります。プログラムの各1行がプログラムが上の部分に印刷されその下に穴が空いた紙カード1枚に相当します。

 

長いプログラムになれば相当数の紙カードになるわけで、それを専用の箱に入れて持ち運ぶのですが、誤って落とし箱から紙カードがこぼれた場合は紙カードを最初から並べ直す必要があって、それだけで大変な作業です。

 

プログラムの修正には該当する紙カードを自分で1枚ずつパンチし直すのですが、打ち間違えるとその紙カードは捨てるしかなく時間と資源の無駄使いとなる。

 

コンピュータ操作はJCL(Job Control Language)というコマンド文を入力して行います。例えばFORTRANのプログラムをコンパイルする場合には、まずアサイン文で紙カードリーダーをソースコード入力デバイスに指定して、次のアサイン文でコンパイラのメッセージ出力をラインプリンタに指定し、最後のアサイン文でコンパイラのオブジェクト出力を紙テーブにした後、FORTRANコンパイラを起動して初めて実行される。もちろんFORTRANのコンパイルエラーが消えるまで、紙テープ出力のアサイン文は入力しない方がいいのは明らか。

 

このJCLコマンド入力操作を専用に行う人員がオペレーターと呼ばれる職種に該当します。私はプログラマーでしたが、当時、C社はプログラマーとオペレーターの両方を派遣していた。

 

1980年4月には、三菱電機鎌倉製作所の職場に派遣されたが、数年前から派遣されていた同じC社の先輩の方々約十人にその年の新人が約十名加わる形になった。

 

またその中にもサブグループがあり、先輩二人に私を含めて新人二人という構成で先輩一人に新人一人がつくことになった。もう一人の新人は中央大で数学を専攻していた人で、入社前に一か月ほど英国に語学留学していたそうで英語は堪能だった。

 

私がついた先輩は筑波大で物理学を専攻していた人で、朝永振一郎に憧れて筑波大に入学したと言っていた。朝永振一郎の講義を聞いたこともあるとか。酒が苦手な甘党で、一緒に残業した後、夕食前なのにミスタードーナツに誘われたこともある。

 

当時、暮らしていた武蔵小杉の寮の私の前の部屋にも、同じ三菱電機に派遣されていた先輩が住んでいた。その先輩は兵庫県の神戸市出身で関西学院大の情報関連の学部を出たとか。兵庫県北部出身の田舎者の私と違い洗練された都会人という感じで有能な先輩だった。その神戸市出身の先輩だけがC社の三菱電機グループの中でただ一人情報処理の1種の試験に受かっていた。また他には和歌山大出身の先輩もいて近畿の関係者も数名いた。

 

現在は情報処理試験にも職種に応じて様々な試験があるようだが、当時は情報処理の試験はシステムエンジニアが目指す特種と上級プログラマー向けの1種と一般に下級プログラマーと認定される2種の3種類しかなかった。C社では情報処理試験に合格すると毎月手当が出る仕組みが導入され試験合格が義務付けられていた。特に特種の試験は難しくC社全体でも特種を持つ人はごく少数で特種試験に合格すると全社的な話題になったものだ。ちなみに私が今まで会った人で特種に合格した人は一人もいない。

 

5月以降は残業も増えた。遅くまで残業した後、寮の自分の部屋で眠い目をこすりながら情報処理試験の問題集に毎日取り組んだものだ。

 

その頃、私は体調を崩してその後の教訓としたことがある。遅くまで残業した後に寮の最寄り駅の武蔵小杉についてから夕食を取っていたのだが、その場合寝るまでに2時間以下しかない間隔がとれない。それが長く続いた後、夜中に吐いて胃潰瘍に近い症状が出てしまった。胃が痛くて全く食欲がない。夕食から寝るまでの時間がみじかすぎたのだ。

 

三菱電機の鎌倉製作所にも社員食堂があったが狭くて昼食は全員が業者が納入する弁当を食べていた。残業する場合は夕方頃にカップラーメンやサンドイッチ等を買ってきて一時しのぎにする場合が多かったが、長く残業することが確実な場合には狭い社員食堂に行って夕食を食べるようにした。業務の関係で時間が取れない場合は残業が終わった後に大船で夕食を食べた。大船から武蔵小杉までは横浜駅を経由してJRから東急線に乗り換えるので約1時間かかる。それで夕食から寝るまでに約3時間の間隔が取れた。

 

その経験から、夕食から寝るまでに3時間はとることが私の習慣になった。

 

8月にはC社の新人研修の一環として富士登山があった。土曜日の朝に新宿本社前に集合してバスで富士山に向かった。バスで行ける所までいってその後は徒歩だが、ジーパンに運動靴という普通の恰好だったと思う。途中、山小屋で一泊したが頭と足を交互に並べる方式で寝返りもしにくく殆ど眠れなかった。だた夜は冷えるので屋外よりは暖かかったはず。暗いうちに山小屋を出発したが空気が薄いせいか頭痛が常にしていた。頂上近くになると傾斜も急になり両手を使ってやっと登れる感じだった。ただ頂上に着くと予想より広い敷地に電灯が煌々と灯り多くの人が歩いている、値段は高かったが土産物屋や食べ物屋もあった。

 

富士山の頂上で夜が明け始めたが、雨模様の曇り空で小雨も降っており、ご来光は見えなかった。下山途中、砂走りを歩いて降りたが、霧か靄が濃くて数メートル先も見えない状況の中で、黒くて粗い砂利の斜面を延々と下る、何かこの世ではない幻想的な場所にいるようで不思議な体験だった。ただ運動靴の中に入る砂を何度も靴を脱いで取り出す必要があったのには閉口したが。

 

かなり長文になったので、今回はここまで。