WICS(Integer Interpreter Compiler System)は、MZ-80K及びMZ-80B/2000/2200シリーズで主要に使われていた、同時代のZ80システム用のBASICライクなコンピュータプログラミング言語、ないしその処理系。

## 概要

WICSはBASIC(当時のマイコンのそれ)に似た表記方法を採用した高水準言語で、処理系としてはインタプリタもコンパイラもあった。処理速度とRAM領域が限られた8ビットパソコンで、容易に高速なアプリケーション、特にゲームを作成する目的で開発された。

工学社のI/O誌1981年9月号より連載記事の形で、MZ-80K/C版のインタープリタ(バージョン1.1)のアセンブラ言語BASE-80で記述されたソースコード、コンパイラ(バージョン1.2)のWICS自身で記述されたソースコードが公開された。後に発刊された「I/O別冊 WICS・BASEプログラム集」では、MZ-2000向けのインタプリタ(BASEアセンブラによる記述)・コンパイラ(WICSによる記述)の全ソースコードが掲載された(MZ-80B向けでは、I/O本誌連載時にコンパイラのみソースコード掲載)。

製品版は、カセットテープ2巻(インタプリタとランタイム、コンパイラ)でキャリーラボから販売された。

MZシリーズのアプリケーション作成ツールの主流の一つとなったが、他のプラットフォームの処理系は、キャリーラボからの発売のみか、発売されていないものさえあった。
例えば、NEC各機種(PC-6001、PC-8001、PC-8801)やMZシリーズ各機種用は販売されていたが、X1用は販売されておらず、キャリーラボ製のゲームで使用されているのみである。

また、WICS/BASEシステムのディスク版として、C-DOSがCarry labより販売されていたが、これはCP/M等と異なりシステム構成としてはF-DOSに近いものであった。
C-DOSも、販売されていたのはSHARP MZ-80B/MZ-2000とNEC PC-8801用のみであったが、PC-8801SR対応版もMZ-2500の3.5インチドライブ対応版も販売されなかった。
C-DOSは、X1、FM-7、PC-9801用等も開発されておりゲームに組み込まれているため、WICSはZ80の主要機種、C-DOSとBASEは当時の主要機種すべてに移植されていたようである。
後にC-DOS IIがPC-8801とX1turboで大成功したが、旧C-DOSはまったく違うものである。

## 言語仕様

ステートメント(文)と関数がある。

(簡易なBASICであるTiny BASICなどにも良くあった機能制限であるが)扱える数値は8ビットか16ビットの整数のみで、文字列を編集するような機能も無い。代わりにメモリ操作やビット操作、画面表示関係などの機能を持つ。

リテラルには、16ビットの範囲の十進または十六進表記、及び1文字分の8ビット文字コードがある。変数は16ビットのみである(8ビット文字コードを変数に代入すると上位8ビットは0でパディングされ、変数を文字として出力する場合等では上位8ビットは捨てられる)。

配列は8ビット配列と16ビット配列とがある。実体としては、使用するメモリ領域先頭のアドレスを変数に与える。要するにポインタであり、適切に使用しなければ任意のメモリの内容を壊してしまう。

文字列は、特定のステートメント及び関数の引数としてのみ使用できる(文字列からポインタを得るような機能は提供されていない)。

BASICの基本的な制御構造と同様のものの他に、Pascal風のREPEAT - UNTILがある。

標準ストリーム的な考え方も取り入れられており、PRMODEステートメントにより、同一の出力命令からの出力先をディスプレイとプリンタとで切り替える。上記のHello worldは、PRMODE 1に変更するとプリンタに印字される。

多くのBASICと異なり、機械語プログラム呼出し機能の USR が関数であるため戻値を得ることができる。機械語ルーチンはHLレジスタに引数を設定して呼出され、HLレジスタに戻値を入れて戻す。

## 処理系

インタープリタでも発表当時に存在した他の処理系と比較してかなり高速な上、コンパイラを使えばさらに高速実行が期待できた。

インタープリタは、BASICと同等の操作で使用できる。標準のメモリマップではインタープリタが使用する変数・スタック領域が2304バイトしかなく、一定以上のプログラムを作成する際にはメモリ割り当て(ソース格納開始位置)を変更する必要がある。スタックサイズは512バイトで、変更できない(スタックサイズ変更を前提にしたソースプログラムは、インタプリタでテストできない)。

ソースプログラムのステートメントや関数からは、コンパイル時にほぼ1対1に対応する機械語が生成され、前後のステートメントにわたっての最適化はなされない。ランタイム呼出しやサブルーチン呼出しでは、HLレジスタやスタックを操作する機械語が多くで生成される。他の処理系と比較して高速であったために、コンパイラを複雑化させる最適化が試みられなかったとも考えられるが、この点において、WICSコンパイラは高級言語処理系というより、高機能なマクロアセンブラであったといえよう。なお、局所的にはJPとJRの最適化は行われたが、これはキャリーラボが既にBASE-80に実装している。

コンパイラが生成した目的プログラムは、ディスプレイのリフレッシュレートとの同期を行わない。このため、BASICの感覚で画面出力ステートメントを記述すると、実行時に画面上にノイズが現れることがある。

ランタイムは、インタープリタ、コンパイラ、目的プログラムのいずれもが共通に使用する。2560バイト~4608バイトと小型であり、各種の標準ルーチンと、機械語モニタを含んでいるが、
MZ-80B/2000用等では、他に5376バイトのTSモニタを必要とする。

コンパイラが生成した目的プログラムは、ランタイムのみを使用する(インタープリタ本体は使用しない)。このため、インタープリタに上書きして目的プログラムを生成することにより、ランタイムと目的プログラムを併せた連続占有メモリを小さくできる。

## 利用の実際

BASICに似た文法構造のため、BASIC経験者にとっては修得が容易であった。

それまでMZ-80シリーズのゲーム開発で人気があった、ハドソン製のFORM(整数型Tiny FORTRAN)に代わり、ゲーム開発用言語として一定の人気を博した。前述のI/O及びその姉妹誌では、発表されるプログラムの作成ツールでは主流となった。

一つの仕様の言語が、インタープリタとコンパイラとに共通で適用できることにも魅力があった。処理系がコンパイラのみの場合、OSのない当時のPCでは、目的プログラムのテストランは失敗時にハードウエア・リセット以外の復旧方法がない。MZシリーズではカセットテープからの再読込が必要となる。この問題に対してWICSでは、コンパイル予定のプログラムを、比較的安全にインタープリタ上でテストランできる。

インタープリタの設計がテストランを意識している傍証として、VLISTコマンド(プログラム停止時の変数の値を列挙する)の存在を挙げることができる。

## その他

- 開発元のキャリーラボだけではなく、他社からもWICSで開発されたゲームが複数タイトル発売された。但し、キャリーラボはランタイムを含めた目的プログラムの製品版開発に関してフリーとしていたわけではない。WICS製品版に同包されたマニュアルには、機種によってはランタイムと目的プログラムをまとめてセーブする方法が記載されているものもあるが、製品利用に関して自由に使用できないことが明記されたものもある。
- アセンブラで作成された当時の一定規模のソフトウエアとしては、非常にバグが少なかった。