FORM,WICS,GAME,TL/1..8ビット機の独自言語
FORM,WICS,BASE,GAME,TL/1,K Compiler,SLANG 等
8ビット機の独自言語について語りましょう。 I/O
FORM(ハドソン)
Tiny Fortran。初期のMZ-80のゲームはこれが多かった。
WICS(キャリーラボ)
Integer Interpreter Compiler System の略
配列の扱いがなかなかおもしろかったですな。
BASE(キャリーラボ)
BASIC ライクなアセンブラ。if や while も使えました。
K Compiler(COMPAC 津田伸秀?)
FM シリーズ用というか 6809 の特徴を生かした構造化言語。
他に PALL とかいろいろあったと思いますが失念。 ASCII
GAME(作者?)
最初はインタープリタ。のちにコンパイラも登場。
MZ-80,PC-8001だけでなくApple用なんてのもありました。
Vz のマクロを見ると思い出す。
TL/1(作者?)
構造化言語。名前の由来は PL/1 ?
この2つはあまり詳しくないです。 S-OS (Oh!MZ/Oh!X)
Fuzzy BASIC
構造化BASIC。のちにFuzzy BASIC自身で記述されたコンパイラも登場したと思った。
SLANG
構造化言語。Z80 に特化した機能を持つ。
TTI/TTC
GAME の S-OS 版?
S-OS には通常のアセンブラやFORTHもありましたが独自ではないのでパス。
Oh!MZやOh!X はとっておけばよかった.. GAMEやTTI/TTCはVTL(Very Tiny Language)の拡張ですな。 >>2
PALLはパスカル風のやつですね。
FORMのほうが実用性は高かったように思います。 >>2
BASE
whileは使えなかったよ。ifも1行の中だけでしたけど。
S-OSなどに持っていけたら面白いけどなあ。
WICS
市販ソフトも書かれていたようでした。
キャリーラボは言うに及ばず(BUG FIREはWICSで書かれています)、
コソーリとポニーキャニオン(プロジェクトAはあからさまにWICS)、
許諾を受けて堂々とデービーソフト。
しかし後者はその後キャリーラボと・・・(以下知ってる人は多数なので略)。
>>5
VTL ってのは知らなかったです。やはりASCIIあたりで発表されてたのでしょうか。
ところで最初のGAMEってどの機種用だったのでしょう?
>>6
PALL はコンパイラじゃなかったんでしたっけ。
一時期PascalがBASICの次に標準搭載の言語になると一瞬盛り上がったような。
TurboPASCALが標準搭載のマシンとかだと良さそうだよなぁ。
>>7
LOGOっつーとタートルグラフィックス。これも教育用といいつつ廃れましたな。
>>8
あ、whileはないんでしたっけ。ループはあったような気がしたんだけど、あれって
DJNZ 用だったのかな。使ってたはずなのにすっかり忘れております。
バグファイアはWICS/BASE本にソースが載ってましたね。捨てなければよかった..
市販のソフトに使っても問題なさそーな気もしますが。まずかったのかな。 ttp://exo.com/~wts/mits0004.HTM
↑VTLについてちょこっと解説があります。
ttp://www.nk.rim.or.jp/~jun/game86/
↑あとついでにDOS用GAME。 >許諾を受けて堂々とデービーソフト。
>しかし後者はその後キャリーラボと・・・(以下知ってる人は多数なので略)。
MZで出てたアレは持ち込みなのであんまりdBとは関係ないよ。 LOGOを8ビット機の独自言語として語ったら可哀想。
LOGO誕生は1967年で、Cとかよりも古く、i4004より前なんだよね。
(このレス書くにあたってネットで検索し、再発見してオレも驚いたんだけど(w)
元来フルセットのLOGOはLISPばりのリスト処理系を含む、人工知能指向の高級言語。
なんだけど、CAI向けということで、そのタートルグラフィックス機能のおもしろさ
だけが注目された感がある。どの雑誌か忘れたが、80年半ば頃にLOGOを使った
人工知能入門連載なんかもあったけど、「LOGOの隠れた魅力」的な扱いをされていた。
確かにその頃はLOGOブームみたいな雰囲気で、多くの雑誌にタートルグラフィックスや
リスト処理を省略したLOGOのサブセット版みたいな言語の記事が掲載されたよね。
SONYのSMCなんかはBASICに標準でそういう機能があったんじゃない?
;ところで、なぜこの板はsage進行のスレが多いん?ここなんか今日の夜明けにできたばかりなのに。
;そういうルールでもあるの? >>12
sage進行が多いのは、冬厨や粘着くんの出現を抑えるための自衛策。
もう大丈夫だろうけど。 WICSとBASEばっかり使ってました。
I/Oに載ってたWICSコンパイラを打ち込んで、セルフコンパイルかけたら
4時間くらいかかったと思います。
取っ付きにくかったマシン語も、WICSに慣れたらすんなり入れましたし、
後々Cを習得する時に何の抵抗もなくいけたのも、WICSのおかげでした。
今の自分があるのは、WICSのおかげです。感謝。 他スレにも書いたんだけど、NCBを使った方いませんでしたか?
任意桁数の数値計算ができるってやつなんですが。 >>13
了解。
肝心の8bit機コンパイラの話をしてなかった。
Kはよく使ったなあ。吐き出すコードが印象的だった。
お世辞にもオプティマイズされてるとはいえなかったけど、
スタックを多用した6809ならではのもの(後にZ80機にも移植されたけどね)。
まだ6809始めたばかりで、豊富なアドレッシングのありがたみなんか解らず
プログラムしてた頃だったから、コード見るたびに、
「ほら、こんな風に書いたっていいんだよ」
と言われてるような気がしてた。 >>11
書き方が少し悪かったかなあ・・・。
これはデービーの辞書盗用を書いたつもりなんですが。
「身内の始末もできない団体が人のことをとやかく言うな」と思ったのは
私がリアル工房のころ。
>これはデービーの辞書盗用を書いたつもりなんですが。
イヤ、分かってるけど。
>「身内の始末もできない団体が人のことをとやかく言うな」と思ったのは
>私がリアル工房のころ。
この辺は意味不明です。ひょっとして ACCS のことを言ってるのかな?
たしかdBはあの団体には加盟していなかったハズだけど… リアル厨房んとき、ACCSに「他者の辞書をコピーして使ってるdBソフトは
どうなんだ!!」って電話掛けたことあるんよ(若いな…)。
したら「あ〜dBはウチの会員じゃないですね。どうかしました?」とか言わ
れたよ。 >>3
最初のGAMEはH68/TRじゃなかったけか。
>名前の由来は PL/1 ?
TL/1はPL/1に掛けているが、Tiny Languageの略ですね。
変数が1バイトだったのが斬新といえば斬新。
>>5
メモリの少ないワンボードマイコン用の小型言語だったのですね。
しかし 768bytes で言語が動くってのはすごいっす。
>>15
NCB ってのはどの機種で動いてたんでしょう?
>>20
その通りで H68/TR が元祖みたいですね。
一番多くの機種&CPUに移植された言語のような気がします。 >>18 >>19
あ、デービーはACCS非加盟だったんですか。実は追放された?
(キャリーラボはあぼーんするまでACCS加盟)
>>20
んぁ?H68用って移植だったはずでは?と思ったが、そういえば
H68TR+どっかのディスプレイボードが最初で、しばらくしてタートル
グラフィックなどを追加拡張したものがH68TR+TVに移植されたんでした。 >あ、デービーはACCS非加盟だったんですか。実は追放された?
ん〜わからん。でも最初は加盟していたような気がする。
フラッピーでヒットを出して、春望で辞書ディスク盗用、始皇帝で画面
レイアウトにケチがついて、177で国会で取り上げられたんだっけって
スレ違いスマソ。
そう言えばdBもBASICコンパイラ出してたよね。独自言語とは違うか。 >>24
スレ違いにも思うがage進でいくよ。
で、そのdB-Compilerなのですが、機能を限定したdB-IBASICのそれですよね。
「ボコスカウォーズ」のMini Hu-BASICよりは自由度が高かったような気がします。
市販ソフトにも「Mr.Pac!」(ナムコへの当てこすりが派手なゲーム)にも使われており、
パッケージにはdB/COMPILER©のランタイム使用許諾シールが貼られていたのを思い出します。
>>23
ttp://homepage1.nifty.com/je2rfo/hal09.htm
を見ると H68/TR→TK-80BS→TRS-80→H68/TV→PET2001→MZ-80K
→Apple→PC-8001→FM-7という順番みたいですね。GAME-86も含めると
6800,8080,Z80,6502,6809,8086 と一昔前の CPU ほとんど制覇しとります。
>>24-25
dB-BASICというとX1が有名ですが、実はMZ-2000用も出てました。
疑似PCG機能とか面白かったのですが、コンパイル後の速度がいまいち
だったんでやっぱりWICS使ってました。
よくよく考えるとWICSもBASICライクな言語だし、標準で付属していた以外
のソフトハウスが出していたBASIC処理系はありかなぁ。 WICS使いだった人って結構いたんですね。
WICS BASEの本はまだ持ってるけど、結局打ち込まなかった。
もっぱらFORMばっかり使ってました。 >>27
わーそれほしい。私はWICS狂いだったもんで。
FORMも懐かしいなあ。
WICSとBASEのリファレンスをハケーン。
ttp://ueno.cool.ne.jp/magicallogic/WICS.TXT
ttp://ueno.cool.ne.jp/magicallogic/BASE.TXT
BASE、while はないけど、DO〜UNTIL がありましたね。
こういう感じで他の言語もリファレンスがありませんかねぇ。 VIC-1001用でPrologのROM版があったね。ROM焼いたけど使わずじまい。
実際にはKコンパイラをよく使ったなあ。あと、あるFM-8用日本語ワープロが
F-BASICコンパイラで書かれてて、なんとコンパイラ本体もワープロディスクに
隠されてて、拝借して使ってた。なんだかコンパイルしても完全機械語の実行
ファイルになるわけじゃなく、一部BASICコードが残ってて呼び出してるみたいで、
劇的に速くなるわけじゃなかったのが残念。第一、ゲームやろうとすればYAMAUCHI
使うしかないし。 TinyBasicはこのスレに入ってもいいのかな?
>>30
こーれは、K/C用WICS,BASEね。
TS-700,TS-200の仕様と標準搭載のモニタとの差異情報求む。 PaloAltoのTinyBasicを日本に持ってきたのが東大版で
石田8080晴久を快く思ってなかった安田6800寿明が電大版をつくって
そのあと確かNAKAMOZU TinyBasicっていうのを大阪の大学が作った。
ぐらいな記憶しか残ってないや。
誰か補完してけれ。
I/OのソノシートがPaloAltoで、bitの増刊のが東大版でいいんだっけか?
でも自分はGAME-80とBASE-80とTL/1しか使わなかったなあ。
TL/1といえばアスキー系で小さくて分厚いZ80用のTL/1の本が出ていた気がする。
しまった、名前に「#=-1」とか気取って入れたら
トリップしてしまった。
鬱だ。
6800の4K BASICってたしか浮動小数点を扱かえたはずだけど、
H68のレベルI BASICは4Kでも整数型だったんだよね。
あのBASICって日立内製だったのかな?
>>39
元の4K-Basicって、テレタイプ(ASR33?)端末用だと思ったのですが
(1文字入出力だけ自分で作る)
H68のは、グラフィックボードで拡張した状態でじゃないのかな〜
「H68のあのキーボードと、あのディスプレイ」でじゃ無かったでしたよねえ…
7セグでAからZまで表示してたもんなー
TL/1は大西博氏だっけ?いま何やってるんだろう。
あとMAIとかあったね。うちにテープアスキーあるけど読めるかな? >>42
MAIはASCII内でもマイナーだったね。 dB-BASICは2種類あってdB-IBASICってのがあったよ。整数型ね。
コンパイラついてたのは後者の方じゃなかったかな。
dB-Iの30KBくらいのダンプリスト打ち込んで使ってみたが
どっかにミスがあって完璧には動かなかった。探す気も起きんかった…。 MZでFORTHってあったよね。
P8ユーザーだった漏れにはとても奇怪なコードに見えた。 >>45
FORTHは今でも使われてるよん。
OpenFirmwareなどなど。
逆ポーランド記法とかで検索しても出てくるよ。
>>46
FORTH というと思い出されるのが Mind。
数少ない日本語ベースの言語。他にはぴゅう太の日本語BASICくらいか。
しかし Mind はちゃんと日本語の文法で記述できるのでした。
思い出されるとか書いたけど、ちと調べたらフリー版が下記で入手できるよーです。
商品版もあるみたいだし実は現役なのね。
ttp://mindclub.scripts-lab.co.jp/ >47
確か88用に和漢つーのがあったぞ。
漢字も使える構造型日本語BASICだったと思う。
雑誌の紹介でしか見たこと無かったが。 >>49
探してみました。
ttp://www.ipsj.or.jp/members/SIGNotes/Jpn/08/1983/029/article002.html
肝心な本文がパスワード要求されるんで読めないんですが、ワープロ感覚で
プログラミングってことは本格的な日本語ベース言語っぽいですね。
元になった AFL ってのはどんなのなんだろ。
そーいえば MZ-2500 は BASIC の変数に漢字が使えたような気がする。 >>50
>>そーいえば MZ-2500 は BASIC の変数に漢字が使えたような気がする。
使えるよ〜。しかもX1のSHARP-HuBASICと違い、ブラケットなしで使えます。
ex.
Hu(ハドソン):[名無しさん]=7743
MZ(テレシステムズ):名無しさん=7743
>>51
そーいえば X1 でも使えてたんだった。
でも昔の漢字の入力形式だと面倒だから漢字の変数名使う気しないんだよなぁ。
X1 の NewBasic あたりでちょっとは漢字入力が楽になったような気がする。
日本語の言語、最近だと「ひまわり」というのがあるようです。 やふおくでWICS・BASEプログラム集をかっぱぎました。
もうすぐ旧友に会える・・・今はそんな気分です。
I/O 1983年4月号544p.より。
新製品:WICS-8001 \12000 ROM+TAPE
そんなのあったの!?!?!?!初耳です。
なお、WICS-700も広告に出ていますが、存在は知っていますし、>>55で
かっぱいだ単行本にもあります。
WICS BASEプログラム集ですかぁ。いいなぁ。
やっぱ捨てなきゃよかったなぁ。
そーいえばKは非構造化言語でした。最近引っ越した
んすけど、なぜか言語関係の記事が載ってるときの
I/Oとかは残ってたんで、Kの載った号も見つかった
のでした。 >>56
気ぃ悪くするかもしれないけど、そのかっぱぐって言葉やめません?
凄く品がない人みたいな印象を受けるよ。
聞こうか迷ってたんだけど、かっぱぐってどういう意味ですか? kumajiri使ってた人はいないのかな。いないか。 >>59
分捕る、掠め取る、の意味でも使われるので、あまり上品な言葉では
ない。
「パチンコかっぱぎ講座」って本もある。 >>58-62
やっぱり「かっぱぎ」はやめよう・・・ヤフオクにはぴったりなのですが。
それはさておき、>>63は思ったより上がらないと思いますよ。
状態云々よりも、需要が一段落したからと思うからです。
>>3
ASCIIによると(持ってるのはENCYCLOPEDIA ASCIIの5ね)、GAMEの製作者も「大西博」って人らしいです
>>61
KUMAJIRI…名前しか聞いたことないです。
あとはFAST(Tiny FORTH)とか、TTLとか… KUMAJIRI…
ASCIIの読者コーナー(TBN)でベンチマークが語られて
実際はI/Oに出てたような気がする
津田さんだっけ?作者
6809用でしたっけ…それであまり記憶がないのかな
kumajiriの作者は津田さんです。K compilerのKはたぶんKumajiriのK。
で、kumajiriの語源は...内緒 :)
I/Oに出てました。文法は構造化GAME言語。6800用で、
コンパイラ-インタープリタ型です。結構画期的だったと
思うけどなあ。
津田さんってViViの作者さんですよね。
ホームページみても昔の言語についての記述がなさそーなのでちと残念です。
FM-7用のCもそうでしたっけ? >>67
Kコンパイラの作者は桂さんでは?
>>68
FM-7用のCは、いくつかあった。
I/Oで発表されて、Oh!FMで発展したのが、Draco-C
ざべで発表されたのが、DOH-C。多分こっちが津田さんの作品 >>80
KumajiriとK-compilerは別物です。
発表はI/O誌1980年8月号103ページ。
表紙では「幻の68系コンパイラ『KUMAJIRI』全リスト公開」と
紹介されています。作者は津田伸秀さん。
文法は構造化っぽいGAME言語。行番号の代わりにラベルを使い、
構造化構文(if-else-then、for-next、repeat-until、while-wend)を
追加したような言語です。 71です。ごめん、さっきのは >>70 の間違い。
K-compiler って、Kumajiriをちゃんと設計しなおした言語、だったと
記憶しているんですが、資料がでてこないので、もしかしたら
私の記憶違い? KUMAJIRIに関する津田さん本人の投稿がASCII誌80年1月号のDMAにあるんだけど
どうしてI/Oに逝っちゃったんだろ。(結果的には良かったかも)
例によって何ヶ月も投稿を未チェックのまま積んでおかれたのか? K Compiler、発表時の名前は COMPAC T&S になってますね。
実は共作? Agenda TIA/D 整数型コンパイル言語
AGOS上で動くやつ
良かったんだけどなぁ、、、 ASCIIでFM-8とか09マシン用にコンパイラが出ていた。
CONSOLっていう名前だったと思う。
PASCALっぽいかったような・・・、誰か知ってる? 最初に覚えたのがTL/1
おかけで由緒正しいPASCAL派になってしまったが
PASCAL系といえば、FM用にModula-2/09なんてのもあったな
>>77
COMSOLで検索したら情報が見つかりました。ありがとうございます。
>PASCAL系といえば、FM用にModula-2/09なんてのもあったな
OS-9/6809が必要だったので
貧乏な私はリストを眺めているだけでしたね。 ttp:/www.nk.rim.or.jp/~jun/rvtl/rvtl.html
これは32ビット版のGAME III? 月刊マイコンで発表されてたPコンパイラってのもあったね(FM7用)。
多分作者は津田さん。
KをよりC言語っぽくした感じ。
後づけでPlayコンパイラとかも呼ばれてたっけ。 >>81
そうですね。変数とかが32ビットになってるので行番号が21億までってのはちとワラタ。
アセンブラオンリーで開発ってのは最近ではめずらしいんじゃないかなぁ。
VTL系言語の歴史というページの一番下の、
塚越一雄, オリジナル言語入門, 電波新聞社, 1988, ISBN4-88554-158-1
って本が読んでみたい。 独自の言語ってゆーかCなんだけど、FM用のDOHC。
ネーミングセンスがすげぇと思った。 S-OS系のネーミングセンスだと
SLANGとか(最初わからずに「えす-らんぐ」と読んでいた(^_^;)
TTLとか。 PC-6001 の EXAS というBASIC コンパイラもあった。
作者は今も有名人 ttp://www.pro.or.jp/~fuji/
20年も前なのね。 SHARPもMZのインタープリタパスカルを出してたなぁ。
ついでにMZ-80のHu-BASICはコンパイラがあったぞ。誰か使ったヒト居ない?
MZはとかくテープベースで使えるコンパイラ言語がそろってて良かった。
面白かったなぁあの頃。 >>88
それ、I/Oにも初期版がリストに載りましたよね。当時打ち込んで、
この為にROMライターまで製作しました。今でもあるのですが、
焼けるのが2764だけだったかな。今頃こんなEP-ROM売ってないですね(苦笑)。 そうそう、あとASCIIに載ったGAMEコンパイラ、GAME-SMCを使っていました。
MSXにも個人的に移植したんですが、独特な(ドキュメント性のない)記述が
いやになって飽きてしまいましたが…。
確かGAMEってその後PC-98に移植されてGAME2とか出ていたような記憶があるんですが…。 WICS.BASEにはお世話になりますた。
工学社の本ももっと続けて出してくれればよかったのに >>89
Hu-BASIC Compilerは、先日ヤフオクに出てますた >>92
GAME2って知らないなぁ。 詳細キボンヌ。 GAME2 じゃないけど…
http://www.nk.rim.or.jp/~jun/game86/ >>97
あ、それそれ、それだ!
ありがとうございます。ダウンロードしてみよ。 MAIっていうのもあったよねN-BASICモードの
GAMEやTL/1に構造化命令拡張したようなやつ
確かGAMEは最後にSMC-70に移植されて関数が3文字になってわかりやすくなったのが8ビットでは最終版だったかな
TL/1はMSX-DOSのが最後だった気がする
なつかしいな 100ゲットズサー
10ヶ月かかりますた。
MAIは>42-43あたりでちょっと出てますね。
昔は構造化でも高級だったのだなぁ。まあOOPは実装しきれんでしょうが。 8bit時代ってBASICコンパイラユーザーがやたら馬鹿にされていたが、
(かくいう俺はBASICコンパイラなんて買えない貧乏人だったが)、
今思うと、ハードメーカーもガンガンBASICコンパイラなり独自のコンパイラ言語なりを
本体に付属して、べーマガで優位に立てるようにすりゃよかったのに、と思うな。 Oh!MZのプレゼントでインタプリタPASCAL貰いました
今ではDelphi使いです >>101
>8bit時代ってBASICコンパイラユーザーがやたら馬鹿にされていたが、
馬鹿にされていましたっけ?
その当時すでにべーマガを読む世代ではなっかたので、解説キボン。 ベーマガにBASICコンパイラ推奨のゲームってあったか?
BASICコンパイラは馬鹿にされてなかったと思うが、ランタイムがデカくて
やりにくいなぁ、という感じはあった。
8bit時代には、みんなが普通に言語を作って競い合っていたように思う。
最近はどうなんだろう。現代の高級言語はC++、Java、Perl、PHPなのか?
もっと高級なものがあっていいと思う。
ユーザーが馬鹿にされたというより、Basicコンパイラが馬鹿だったヨウナ気が。 >>104
コンパイラ使用のソフトを投稿するとかなりの確立で採用されるのはやはりPiOだったでしょう。
PC-6001のEXASコンパイラ作品はいうに及ばず、MZのWICS、X1のdB-Compiler、
あげくには雑誌公開していないはずのPC-8801版dB-Compiler使用ソフトまで載る始末ですから。
ほかの雑誌ではごくわずかにOn!MZで出たぐらいです。
(「1日1面FANTIC」はMZのdB-Compilerで書かれたものです)
8bit時代にコンパイラが頻出したのは、マシンの制約が大きかったからだろうな。
実数型・4PASSのBASICコンパイラを気合入れて作ると、コード入れるエリアが無く
なってしまうし、じゃあBASICで良いかというと遅いし。
テープ主流の頃は、いかに妥協して目的に合ったものをコンパクトにまとめ上げるか
という目標があったけど、最近のWin機だと、メモリがぶ飲みしたところで、どう
ってことないからなぁ。
.NETの開発環境なんか、メモリ強烈に食うもんな。
こんなんじゃ、作り込む楽しさなんか味わえないよ。 >>108
>作り込む楽しさなんか味わえないよ
うむ
久しく忘れていたような気がする FM-7でKコンパイラを使っていたが、sin cos関数がないので、
自分で簡易sin cos変換テーブルを用意することを覚えた。
人のプログラムを見て、なるほどと思って、感心したんだが、
そんなことにも喜びがあったなぁ。 >>114
sin, cos をテーブル用意してやるのはよくやったなあ。
今だとコプロのってるから意味ないんだろうけど。
三角関数にテーブル使うのとかZ80みたいに割り算命令のないCPUの場合に
シフトで演算させるのとか、みな失われた技術になってしまうのかな。 あんまり詳しくないんだけど、もしかしたらコプロの中にテーブルがあったり、CPUのマクロ命
令の中でシフトしてたりするんでは・・・ >>115
組み込みでよく使われるARMはコプロも除算命令もありません。 >>115
PSone用のゲームとか組む場合は未だsin/cosテーブルは健在じゃないかな。 >>117
ARMでアセンブラで組むことはほとんどないと思われ。 >>118
PlayStation の CPU ってコプロ載ってないのけ? ______
/_ |
/. \ ̄ ̄ ̄ ̄|
/ / ― ― |
| / - - |
||| (5 > |
| | | ┏━┓| / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| | | | ┃─┃| < こんなサイトを見つけた
|| | | | \ ┃ ┃/ \ 正直、スマンカッタ
| || | |  ̄ \_________
http://freeweb2.kakiko.com/mona/ >>121
不動小数点演算のためのコプロセッサは載ってないよね。
そのかわりベクトル/マトリクス演算用のコプロセッサがある。 ━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―
__∧_∧_
|( ^^ )| <寝るぽ(^^)
|\⌒⌒⌒\
\ |⌒⌒⌒~| 山崎渉
~ ̄ ̄ ̄ ̄ ハッキリ言ってアメリカなどの多民族国家では黒人の方がアジア人よりもずっと立場は上だよ。
貧弱で弱弱しく、アグレッシブさに欠け、醜いアジア人は黒人のストレス解消のいい的。
黒人は有名スポーツ選手、ミュージシャンを多数輩出してるし、アジア人はかなり彼らに見下されている。
(黒人は白人には頭があがらないため日系料理天などの日本人店員相手に威張り散らしてストレス解消する。
また、日本女はすぐヤラせてくれる肉便器としてとおっている。
「○ドルでどうだ?(俺を買え)」と逆売春を持ちかける黒人男性も多い。)
彼らの見ていないところでこそこそ陰口しか叩けない日本人は滑稽。 ∧_∧ ∧_∧
ピュ.ー ( ・3・) ( ^^ ) <これからも僕たちを応援して下さいね(^^)。
=〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
= ◎――――――◎ 山崎渉&ぼるじょあ (⌒V⌒)
│ ^ ^ │<これからも僕を応援して下さいね(^^)。
⊂| |つ
(_)(_) 山崎パン ttp://www.cc.u-ryukyu.ac.jp/~hosoya/ronbun/vtlms.htm
ガイシュツだろうけど貼っとく 自分もTL/Iでプログラム組んだことある。
たしか、開平筆算法で根を求めるプログラムだったような・・・
夏休みの自由研究として学校に持って行ったけど、
全然受けなかったような気がする・・・
関係ないけど、作者の大西さんはapple使いだったのかなぁ。
マイクロオセロリーグに出てきた大西オセロはappleで
動いていた気がする。 >>138
アスキーのベンチマークテストで一位だったような・・・
当時は、ベンチマークテストの順位を暗記するくらい見ていた。
今だったら、ベンチマーク厨とか言われそうだな。 Tinyっていう言語+環境があった。
プロローグと同じ、言語であり、環境であるシステムで、
代入文のみという割り切ったやつだった。
A:=B っていう感じで、Bに環境変数を入れたりした。
N-BASICでできることは大抵できたと思うが、
代入文たった1つしかないプログラミング言語+環境というのは
今考えるとスゴイ。 rvtlオモスレー
なんかこう、タイムトリップした感じ
放置してたザウルス引っ張り出して、通退勤時の電車内で浸っております
初パソMSX2な若造なんでGAMEやVTLは知らないんだけどね 手持ちのエンサイクロペディア・アスキーを漁ってみたら、GAME-MZのソースもあった。
物持ちがいいなと思った。 ,.-─ ─-、─-、
, イ)ィ -─ ──- 、ミヽ
ノ /,.-‐'"´ `ヾj ii / Λ
,イ// ^ヽj(二フ'"´ ̄`ヾ、ノイ{
ノ/,/ミ三ニヲ´ ゙、ノi!
{V /ミ三二,イ , -─ Yソ
レ'/三二彡イ .:ィこラ ;:こラ j{
V;;;::. ;ヲヾ!V ー '′ i ー ' ソ
Vニミ( 入 、 r j ,′
ヾミ、`ゝ ` ー--‐'ゞニ<‐-イ
ヽ ヽ -''ニニ‐ /
| `、 ⌒ ,/
| > ---- r‐'´
ヽ_ |
ヽ _ _ 」
ウプレカス [ Uprecus ]
( 西暦一世紀前半 〜 没年不明 ) 漏れも持ってるYo!つうかこれくらい持ってんの多いんじゃね? TL/1がいいのは、レジスタ長と変数の大きさが一緒だったのが大きいんじゃないかな。K&R時代のC言語のように。 すっげぇ遅レスだけど
>>155
俺もやった覚えあるよー TL/1でよくあれだけの規模のプログラム
書いたってのがちょっと驚きだった
>>156
いいのかなぁ
変数サイズが基本的に8bitというのは結構きつい制限のような
覚えもあるんだけどね
もっとも当時は当たり前のようにアセンブリ言語のみで作った
プログラムがあったのだからバランスとしてはよかったのかも
しれないね ・GAME-78Kインタプリタ(作者の悪口を言わないこと等を条件に無料公開されている)
・USBエッジコネクタつき78Kマイコンボード(ボードつき書籍として売られている)
現在これらが出揃ったようですが、これで何が出来るのかはわかりません・・・
antivir english language version,full cracked ^^
http://205.209.140.213:8080/antivir.rar TL/1、再入力して使ってみるかなぁ。たしかFM用もあった気が。
FMの実機も当時のASCII誌もあるのでさがせば出てくるだろう…… RO經典動畫
以改圖的方式呈現另一種風格的RO動畫 ... RO ...
http://www.livedoor-
bbs.com/fortune/ltyy0808033566_5linmovesmm.rar
MSXの大脱走を初めてやった。
てっきり作り直してるんだろうと思ったらPC版からのベタ移植でぶったまげた。
あの頃のキャリーのソフトって88,MZ2000,X1,P6mkII,FM-7間で完全なベタ移植ができてたよね。
ちゃっくんぽっぷとか大脱走とか。
あれってキャリー内で独自コンパイラとか作っててメインプログラムは
全部共用してたのかなぁと思うけど(CPUの違うFM-7が入ってるところがすごい)どうなんですかね?
MSXの大脱走を見て、そのシステムをMSXにまで移植してベタ移植を実現してるんだとしたら
すごいなと思いました。 TL/1はキャリーフラグを意識するところが斬新だった
GAMEは…今作っちゃうとかけ算割り算優先にしちゃいそうで怖い
>>166
もちろんOK。
しかし7年近く経ってもまだ200行かないとは。 しまった8年近くだった。
仕事だと結構独自のインタプリタっぽいのを作るんだけど、
結局構文はCもどきにしてしまうのであった。 掃除してたら押入から石田さんの「マイクロコンピュータのプログラミング」が出てきたよ
TinyBasicのソースにはけっこう書き込みがあったりして
当時の熱意を思い出してちょっと感動 S-OSのTTC/TTIとか、マニュアルは無いんですかね。
OBJだけじゃなく、各言語でプログラムを書けるだけの
情報が載ってるまとめサイトがあるといいのに。
# 連載原稿レベルだとなおいいのに。
TINY言語のリソースセンタとか、著作権確認などの
手間暇と比較して需要がニッチ過ぎるか。 >>67
> K compilerのKはたぶんKumajiriのK。
そのとーり 亀レスだけど・・・
>>3
> GAME(作者?)
> TL/1(作者?)
作者は 大西 博さん
すげえ
まるで歩くエンサイクロペディア・アスキーですね。 当時(1980年頃)のことで聞きたいことがあったら聞いてくれ
知ってる あんど 差し障りの無い範囲でお答えしたげるよ その大西さんは当時何されてた方なんですか?
アメリコから原稿を送ってくる・・・みたいなことが毎回書いてあったんですが >>179
そうだよ
>>180
大西さんを個人的に知ってたわけじゃないし、
彼が何者だったか知らない(すまそ) ご本人様でしょうか。
では質問です。
K Compiler は COMPAC T&S 名義でしたが、共作だったのでしょうか? >182
基本的にはおいらが開発したんだけど、どこか一部(詳細は忘れた)を
工学社(I/Oの出版社)のSさんにやっていただいたので共著ということにしたんだお。
だけど、Sさんは工学社の人だったので著作権料はもらえず、
おいらが全額(定価の10%?)いただいたお。 >>184
回答ありがとうございます。
結構いろいろな雑誌に言語を発表されていたと思うのですが、なぜなのでしょうか。
上の方で Kumajiri は ASCII で話が出たけど発表は I/O という書き込みもあり
ました。基本的には全て投稿で、雑誌のカラーに合わせていた等なのでしょうか。
さらに質問ですが、K Compiler の文法は BASIC ベースで構造化構文を追加
した感じだと思うのですが、文の区切りはなぜセミコロンにしたのでしょうか。
当時押されていた Pascal の影響?
あと、ご自身のページに言語関連の記述がないのが寂しいです。 押す -> 推す ですな。
まだ保存してある I/O をいくつか読み返してみたのですが、1981 年当時に
C 言語の入門講座を連載してたのね。これには驚いた。
まだ -= が =- の時代なんですな。 >>186
Kumajiri が動き始めたときは、中間言語のインタプリタを作成しただけで、
コンパイラやランタイムなどが不整備だったんです。(ASCII で紹介されたのはこの段階)
んで、6809 エミュレータ(on 6800)を開発したんだけど、そのモニタ部分を Kumajiri で
作って、IOに投稿したんですよ。そひたら Kumajiri を是非発表してくれと言われて、
それからコンパイラやランタイムなどを整備して I/O で発表したという次第です。
>>186
> 文の区切りはなぜセミコロンにしたのでしょうか。
C言語の影響だと思います。
> ご自身のページに言語関連の記述がないのが寂しいです。
気が向いたら書くけど、当時のソースなど何も残ってないし
若気のいたり(謎)ってことで見逃してくだされ。 >>187
> まだ保存してある I/O をいくつか読み返してみたのですが、1981 年当時に
> C 言語の入門講座を連載してたのね。これには驚いた。
あれ、オイラがそんなの書いてたっけ?
本人もびっくり(記憶にありませんで) 電波新聞社のマイコンで Pコンパイラ ってのを発表したのは、
電波新聞社の社員の方(彼はもうひとりの社員とゼビウスを開発してた)が、
おいらのコンパイラを気に入ってくれ、彼の意見(ファンクションキーを押すだけで
コンパイル、実行が可能とか)をかなり取り入れて開発した記憶があります。 その人はMさんだっと思うけど、彼はゼビウスを開発・リリースした後、しばらくして
退社されて実家の方にUターンされて行きました。
Mさんがいなくなって電波新聞社とは疎遠になってたんですが、
それからしばらくして今度は技術評論社の社員 or 学生アルバイトの方がPコンパイラを
絶賛されてたので、技評に遊びにいって、何故かコンパイラの作り方みたいな原稿を書くことに
なったように思います。
> まだ保存してある I/O をいくつか読み返してみたのですが、1981 年当時に
> C 言語の入門講座を連載してたのね。これには驚いた。
それって津田というペンネームの別の人じゃないですか?
某T大学の(助?)教授が名前のアルファベットを入れ替えたペンネーム(複数)で
いろいろ記事を書いてたけど、そのひとつではないじゃろか? あ、紛らわしくてすみません。C言語の連載をしていたのは別の方です。
単に 1981 年に I/O でC言語の入門講座をしていたのに驚いたということです。 >>194
なんだ、そういうことか。
でも、何故驚かれたのか理由がわかりません。
C言語は81年頃はもっともホットな言語だったと思いますよ。 1981 年当時は中学生でナイコンでしたので言語といったら BASIC かマシン語、
Pascal というのが今後の主流になるらしいくらいの認識で OS ? なにそれという
感じでした。なのでC言語の入門講座やっていたのに驚いたというか、当時は見
事に読み飛ばしてたなあというか。
今調べると BDS-C は 1979 年開発らしいので、やはり当時でも先端を走って
いる方は知っていたのですねえ。とセミコロンはC言語の影響と聞いて思ったので
した。
いろいろ回答いただきありがとうございます。 >>196
いえいえ、おじさんの昔話につきあってくださりさんくすです。
ちなみに日本で初めて C と Unix を紹介したのは東大計算センターの石田晴久氏だと思います。
1981年頃、bit(専門家向けコンピュータサイエンス誌) に紹介記事を執筆されてました。
わたしは1982年冬に某社でバイトを始めたのですが、そこで初めて Unix/vi/C を触りました。
(ハードは vax-780)
それ以来ずっと vi 派です。 いかん、また変な書き方をしてしまった。
1981 年当時ですと大学等でコンピュータ関係を専攻されていた方や Unix をいじれる
環境にあった方は当然ホットな言語だったのでしょうし、マイコンでも CP/M を使っていた
方でも BDS-C でC言語の存在は知っていたのだろうなあという事を思ったのでした。
当時の私はパーコンでゲームができることしか頭になかったのですけどw インターフェース誌がFORTH系をよく特集してたのは、もしかしたら組み込み系に使えると思ったからかしらね?
あの頃はサザン・パシフィックの広告が眩しかった。
C言語がショックだったのは、小文字メインだったことかな。MZ-80Kユーザーだから>おれ
Kコンパイラはまあまあだったな
しかし関数の呼び出しにUとSを両方使って無駄なPUSHをしているのは
吐いたコードを見て「こりゃ効率悪い」って思った
その後DOH-Cが出たけど裏RAMをフルに使ってオンメモリコンパイルする
のでなかなか高速で良かった
ランタイムルーチンも小さかったし >>197
いえいえ、こちらこそ。貴重な発言ありがとうございました。
そもそも私も十分おじさんですし。というかこの板おじさんしかいないような。
bit は読んでなかったなあ。
プログラミング言語Cの日本での初版は 1981/7 らしいですね。
やはり知ってる人は知ってたんでしょうね。
自分の無知をさらしたような。
そして vi は 1982 年から使われてるのですね。筋金入ってますなあ。 >>199
FORTH は移植性と省メモリということで組み込み向きという話だったような。
もっとも私は長年組み込み系やってますけど FORTH 採用のシステムは見た事ないですがw
言語仕様に詳しくないのでなんですが、割り込みとかどう処理されるのでしょうね。
MZ-80 用のC言語は I/O に載っていたのを見たような記憶があります。
{} がないのでなんかのキャラで代用してたような。なぜトライグラフを使わなかったのかは謎。 TTC のテキスト:
http://www2.odn.ne.jp/~haf09260/Unk/ChouKogataCompiler%20TTC%20(1989)(Oh!X).txt
http://www2.odn.ne.jp/~haf09260/Unk/ChouKogataCompiler%20TTC%20(1989)(Oh!X)%20[Refarence].txt
>>178
質問です。
最近Apple II+を手に入れました。
TL/1を使いたいのだけど、Apple IIへの移植版は
月間ASCIIの何年何月号に掲載されていたかご存知ですか?
あるいは、エンサイクロペディアアスキーの何巻か分かるとありがたい TL/1 PC-8001,APPLE2 ダンプリスト
TL/1ユーザーズマニュアル
ASCII, January,1981
エンサイクロペディアアスキーの8巻
電気屋さんの店先でデモってたPC使ってTL/1でゲーム作って、ENIXのプログラムコンテストに応募したのは懐かしい思い出... そういえば昔、「ユキチカしてそうな芸能人」ってのがあったな
TL/1はダンプリストで配布されてソースは無いのだろう。
構文から推測するとALGOLだろう。ALGOL60は実用的な言語でなく実験的な言語で
仕様のみが公開されているもの。実用的な処理系はない。当時は汎用機の時代でUNIXやミニコン創世記以前。
今のPCで使うならばALGOL処理系が近い。 >TL/1はダンプリストで配布されてソースは無いのだろう。
68の頃はソース載ってたよ ALGOL(60)は実装あるだろ。一部の仕様(call by nameとか)に、正確に実現するのは
異常に面倒なのがあるのでそういう所のアレンジとかはあるだろうが。
仕様と仕様書が膨れたことで知られるALGOL 68でさえ実装はあるんだから。
http://en.wikipedia.org/wiki/Category:ALGOL_68_implementation
ていうか、自分が知ってる部分にちょっとでも似てる部分があったら「あれはこれだ」とか
断言しちゃってませんかあなた? >>211が何を言っているのかよくわからん
MZ80K/CのカセットPascal使ったこと無いな?
そいえば「Pascalが、なんちゃらかんちゃらALGOLの略らしいが、なんちゃらの部分が判らん」と
言っていたのは有澤誠だっけ?
TL/1は、MC6800アセンブラ記述のソースコードが雑誌ASCII上で公開されていた。
原本は、日立H68の上で製作されており、
ソースリストがあるから他のCPUにも容易に移植された。
H68/TRのことだろ
ttp://www.st.rim.or.jp/~nkomatsu/evakit/H68TR.html あれよく7セグで英数字全部表示しようと思ったよな〜 スレたってもうすぐ10周年。さすが過疎板だけのことはある。で age てみる。
去年はC言語のデニスリッチー博士が亡くなり(個人的にはジョブスより偉大な人だと
思います)、そして FORM, Hu-BASIC のハドソンも消滅と寂しい限りです。 FORMは懐かしいわ、書籍にあったGENOCIDEゲームいれて改造して楽しんだな。 FORM is a Tiny Fortran interpreter, isn't it?
Did it run on MZ, or PC? >>226
MZ-80
It's just a compiler. やっとこのスレにたどり着きました。
テープ版のTL/1-PC(PC-8001用)持っています。
TL/1-MSX Ver.1(テープ版) Ver.2(ディスク版) Ver.3(MSX-DOS版)もあります。
およそ1年前、シロピョンさんがご自身のブログで記事を書いておられました。
RENJU(連珠)をVer.3で動かしたいです。
誰か助けていただけませんか。
MSX版はエミュレータ上で現在も健在です。 >>229
>RENJU(連珠)をVer.3で動かしたいです。
>誰か助けていただけませんか。
好きに動かせばいいじゃない >>230レスありがdです。
Ver.2のソースはあるのですが、Ver.3ではコンパイルできないのです。
たとえば、ROMOSという関数がVer.3にはなかったりとか。
完全な上位互換ではないようです。 >>231
>たとえば、ROMOSという関数がVer.3にはなかったりとか。
自前で用意すりゃいいじゃん TL/1-PC(PC-8001用)の中に RENJUが 入っているだろう。 この歳になるまで、TL/1で倍精度式とか文字列が使えるって知らなかったyo >>229 >>231
今更TL/1なんてw
人を頼りにしないで自分で解決しろ
もうここへは来るな 8001用のVer.2ってエミュレータで動かないん? >>237
スレタイに TL/1 があるスレでその対応はないだろ。
素直に、シロピョンさんに質問したらよかろうと思う。 > TL/1って何?
TL/I の誤記と思われる。 シロピヨさんのTL/1はけっこう使った。日経サイエンスのPascal記事参考書に。
PascalがなかったからTL/1はアルゴリズム書く時は便利でダンプコマンドなど作った。
数値計算はTL/1が整数だけなのでBASIC使ってた。
なのでRatforやRatbasなどの構造化2-Passプリプロセッサ系はかなり使った記憶がある。 FORTH系は構文がちょっと特殊だった事と整数しか扱えなかったので馴染まなかった。
マニュアルや解説書も専門家向けだったし、LISPと同じで簡単には理解できなかったな。
組み込み向けではなくて実数計算可能であったなら電卓代わりに使えて便利だとは思ったけど実際は違って期待はずれだった。
今、FORTHのコード見ると古い処理系だけあって昔の人々の怨念を感じるので正直怖くてあまり使いたくない(w
流行しなかったというよりも、それだけFORTHって特殊なんだなと思うようにしてる。 X1/turbo/Z 総合スレ17
http://hello.2ch.net/test/read.cgi/i4004/1411315134/220n-
>220ナイコンさん [sage]:2014/11/24(月) 06:32:30.69
>T&Eのプログラムの出来ってグチャグチャにつくって他機種の移植の際ワケワカメで
>一から作り直すってやつだろ? > 内藤談
>キャリーラボの言語で作ってたって
>ハイドライド3の頃はまた違うんだろうけど TL/1他ってgame系みたいに誰か配布はしてないの? コンパクトなインタプリタという点では現在でもGAMEやVTLにある程度の価値は
あると思うけど、低機能低性能のコンパイラであるTL/1やGAMEコンパイラには
もはや実用的な価値は無い気がする。 むしろgameやvtlで組まれた実用コンパイラってあるの? なんでGAMEやVTLで実用コンパイラを組む話になんの?
「むしろ」って、全然話つながってないじゃん むしろ、今時のコンパイラの出力フォーマットに
この辺のトランスレーション付けるべきだよな。
まあメジャーな8bitCPUにさえマトモに対応してない気がするが。 >>255
実用的価値が無いのが何かの理由なら、実用になればいいんじゃないの? >>256
理解してない用語(モドキ含)無理して使わなくていいよ。 >>259
何を言っているか理解できないなら無理してレスしなくていいのよ? > この辺のトランスレーション付けるべきだよな。
www 中間言語インタプリタは普通だけどコンパイラはあんまり見ないな。 >>256
> むしろ、今時のコンパイラの出力フォーマットに
> この辺のトランスレーション付けるべきだよな。
> まあメジャーな8bitCPUにさえマトモに対応してない気がするが。
例えばLLVMのバックエンドとしてGAMEやTL1対応するべき、みたいなこと言いたいのかな?
何の意味があるのかサッパリ分からん。
フロントエンドなら趣味的なあれや学習的なところでは無意味とは思わんけど。 >>262
JavaやC吐くコンパイラなんてゴマンとあるが? >>262
ちょっと何言いたいのか分からん。
中間言語にコンパイルするコンパイラ、中間言語を実行するインタプリタ、
どっちも全然珍しくは無いがそういうことじゃないんだろ? >>272
折角の投稿が相手に伝わらない人が無駄骨折ってるだけなんだけどね。 勘が悪い生徒に教える教室だったら自己紹介から始めなきゃだな。 TL/1コンパイラなどが、組み込み機器に使われる。
手軽なコンパイルと小さい実行コード。
ワンボードマイコンで使うに手軽で良いだろう
制御などにも使える。 >>274
頭の悪い教師をクビにするのが先だよ。
# つーか何の話? スレ違の話題で「勘が悪い生徒に〜」て
# ホントバカとしか思えないんだけど。 >>275
> 小さい実行コード。
言語仕様として8bitしかデータ型なくて効率良くないよ。
素直に今時のコンパイラ使うのがはるかにマシ。 >>275
最近(21世紀)のコンパイラで組み込みの仕事したことある? >>275
TL/1の言語仕様で今時の環境下で動く組み込み用のコンパイラを作るかなんかして
実用しようということ?
それか、昔のTL/1コンパイラを引っぱりだしてきて実用しようということ?
どっちにしろメリットねんじゃね?
いまどきCコンパイラも用意しないマイコンメーカーなんてまずないし。 誰かAVRにでも移植したくて背中押して欲しいって流れなのかこれは? >>281
>>256さんや>>275さんは技術分からん人みたいだしその可能性は無いと思う いや、関係ないスレに出張ってアンチ装ってるツンデレさんの方ね。 >>284
こういう流れでは?
282 >>256さんや>>275さんは技術分からん人みたい
283 アンチ装ってるツンデレさんのかたでしょ 日本人は自虐的だからな。
そんな事無いよちゃんと使えたよと言われるのを待ってる。 >そんな事無いよちゃんと使えたよと言われるのを待ってる。
当時の話なんて誰もしてないのでは?
>むしろ、今時のコンパイラの出力フォーマットに
>この辺のトランスレーション付けるべきだよな。
とか
>TL/1コンパイラなどが、組み込み機器に使われる。
>手軽なコンパイルと小さい実行コード。
>ワンボードマイコンで使うに手軽で良いだろう
>制御などにも使える。
とかって現代の話でしょ? その昔、マイクロマウス大会があった、
迷路の中を自動車が走り時間を競争する。
優勝したのがTL/1を使っていた。 NORIKOだったかな、ASCIIに記事書いてたね。 アマチュアに使えるコンパイラの選択肢が無かったころの話だなあ 今でも同じです。組み込み用のコンパイラはそれほど多く無い。 >>292
大抵はメーカーが純正でCコンパイラ程度は用意するし、IARやGreenHillsとか
他社製品もあるしなあ、TL/1みたいな効率の悪いコンパイラなんて出る幕無いよ。 バカだなあ、用意されてるならそんなもの無い環境作ればいいじゃないか。 そこまで言うなら選択肢が多いものと少ないものを書くべきだと思う。 >>292
>>301さんが「少ないものを書くべき」だってよ そんな事は言ってないよ、オレオレCPUが少ないのはわかりきってるから。 多いと主張したい人なら誰でもいいけど、
罵倒した人と同一視されるから当人以外書かないと思うよ。 >>306
> 罵倒した人
>>260さんのことですか?誰も相手にしてないみたいだし別にいいのでは? スレ違い、板違いの投稿を延々続けてる奴って何考えてんだろ?
注意されても止めないのは自分を確信犯とでも勘違いしてるのかな。 多分スレタイ理解してないんじゃないかな?
メーカー純正とか何の話だろ? > メーカー純正とか何の話だろ?
それらが当たり前となった今となってはTL/1等のおもちゃコンパイラには
実用的価値は無いって話でしょ。
理解してないの?! それでスレ違の投稿繰り返してた訳?? 全く実用性のないレスありがとね。
実用性があるとかメーカー純正の独自言語とか結構じゃないの。
どこで配布してるのかな? >>326
> メーカー純正の独自言語
誰かそんな話してる? それか誤爆ですか? >>330
> 大抵はメーカーが純正でCコンパイラ程度は用意するし、IARやGreenHillsとか
> 他社製品もあるしなあ、TL/1みたいな効率の悪いコンパイラなんて出る幕無いよ。
てのはTL/1の話だから全然スレ違いとかじゃないよね。それで? >>326
> メーカー純正の独自言語
何の話?それかスレ違の話でもしたいの?? >TL/1他ってgame系みたいに誰か配布はしてないの? TL/1にアンチが居るのはわかったから、TL/1「他」の話をしようぜ。 ある要素についてネガティブに書いただけでアンチとは酷いなw
あらゆる要素について礼賛しなければアンチ扱いされそうなスレじゃ
何も話せることなんて無いわw >>335
>TL/1にアンチ
たしかに「小さい実行コード」なんて事実と違うことイヤミっぽく
書いたりするアンチの行動には呆れますが、頭のおかしい人はどこにも
居るので無視したほうがいいと思いますよ! 事実と違うという事は感知してないので、「小さい実行コード」が事実である「他」の話を宜しく。 >>339
そんなもん存在しないのでこのスレでできる話じゃないね。 >>341
> じゃあどの辺が実用的なのかな?
既出 スレの最初のほう位は読んで理解できてから参加しようぜ。 「そんなもん存在しない」ということはどこでわかるの? BASEの記法は今でも便利なことはあるかも。基本アセンブラなので効率も問題ないし。 >>345
わからない人はスレの最初のほうに上がってる言語動作させてベンチマーク取ったり
すればわかるかもしれないよ。 >>251に回答があればする人は居ると思うけどね。 >>348
>>251に回答あったけど「する人は居ると思う」って何の話? 配布しているならベンチマーク取ってくれる人が居るといいよね。 >>351
同意求められても困るけど興味ないからどうでもいいよ。 ベンチマーク取ったりすれば>>340が事実かそうでないかわかるかもしれないと>>347が言ったので、
配布してれば確認する人は居ると>>348は期待します。 ベンチマークっつったって、「1から100まで足す」だけでも
大変だぞ? >>355
誰かがやってくれるはずって主張だから他人の大変さとかはどうでもいいんじゃないの とりあえず屏風から出さずに虎退治を語ってても仕方がない。 TL/1は、UCSD Pascal買えない・CP/M買えない、当時の小僧達が
再帰呼び出しの凄さを思い知れただけじゃないかと。
(俺はαβ枝刈りがNegaMax形式になってビックリした)
モティロン、たらい回し関数が帰ってこなかったり、VRAM化けたりもビックリ。 確かこんなコードが落ちるんじゃなかったか>TL/1(Z80)
自信ないけど
VAR I;
VAR SUMH, SUML;
SUML := 0; SUMH := 0;
FOR I := 1 TO 100 DO
BEGIN
SUML := SUML + I; SUMH := SUMH ADC 0;
END;
が
IXをスタックフレームにしたら
LD A,#0; LD (IX+_SUML),A
LD A,#0; LD (IX+_SUMH),A
LD A,#1; LD (IX+_I),A
_1:
LD A,(IX+_I); CMP A,#100; JNC _2
LD A,(IX+_SUML); ADD A,(IX+_I); LD (IX+_SUML),A
LD A,(IX+_SUMH); ADC A,#0; LD (IX+_SUMH),A
LD A,(IX+_I); INC A; LD (IX+_I),A
JMP _1
_2:
アセムブラ怪しくてスマヌ 8bit浮動小数点(1bit符号+3bit指数部+4bit仮数部)フォーマットつーのもあるみたいだから
世が世ならレイトレぐらいできたかもな>TL/1 >>359
そのZ80コードじゃ1から99までしか足さないけどいいの?
ツーか問題なく_2: までフツーに処理して抜けると思うがどこで「落ちる」って
言いたいのかわけわからん。 >こんなコードが落ちるんじゃなかったか
「こんなソースコードを書くと暴走(又は無限ループ)するんじゃなかったか」
と解釈するのが普通。
どうやら
「こんなコードを出力するんじゃなかったか」
とでも言いたかったようではあるが。 一般人・ライトユーザの集まりでならともかく
こんなスレでくらい出力することを落とす/落ちる/吐くあたりの表現で通じていいと思う そーか、「コンパイラがコードを落とす」って通じなかったか、スマヌ。
>そのZ80コードじゃ1から99までしか足さないけどいいの?
あー、1足りなかったか。
でも本家のFORループは、も少し複雑だった気がする。
これだと
FOR i :=0 TO 255 DO
などの時の処理が出来ないから。 いやいやコンパイラ絡みの話をしたい人になら通じると考えて当然でしょ… 「(こういうソースを書くと)こういうコードに落ちる」なら通じはするが
「コードが落ちる」は変。クラッシュの意味にしかならない。 ソースをコンパイラがコードに落とす
コードをデコンパイラがソースに、、、なんだろ? >>366
> そーか、「コンパイラがコードを落とす」って通じなかったか、スマヌ。
自分の投稿見直してみ ソースコードを生成するコンパイラじゃ無いから、
バイナリを逆アセンブルしたらこんな感じになった気がする。
に訂正しておく。ごめんねいろいろ。 そいや、TL/1の6502版の実装って、スタックフレームどうやってるんだ?
引数と変数領域は自前で管理か? TL/1 AppleII版は作者が中学生だか高校生だかじゃなかったか? >>377
覚えてないけど、ゼロページにフレームポインタを割り当てて
LDY #ARGA
LDA (0),Y
とかでアクセスすればいいんじゃないかな。
Z80でもTL/1が8ビットなのを考えると、引数を積むのにPUSH(16ビット単位)が使えないし、
スタックを使うメリットはあんまり無いような気もする。 >Z80でもTL/1が8ビットなのを考えると、引数を積むのにPUSH(16ビット単位)が使えないし、
使えないわけはない >>380
Z80だとバイト単位でのPUSHは出来ないよw
上位バイト無視とかだとメモリの無駄が多すぎるし。 >使えないわけはない
まー引数を60個近く渡すバカも居ないとは思うが
6502ユーザーからしたらスタックの1バイトは血の一滴以上だからもったいないっちゃもったいない >Z80だとバイト単位でのPUSHは出来ないよw
;AをPUSH
PUSH AF
INC SP >>383
PUSH AFは2バイトPUSHしとるがな
1バイトのPUSH命令はあるの?
そうやって複数命令使ってもいいことにするなら
たいていの「できないこと」は無いことになってしまうな >そうやって複数命令使ってもいいことにするなら
>たいていの「できないこと」は無いことになってしまうな
プログラミングって複数命令を組み合わせる作業だけど何言ってんの?? >>379「引数を積むのにPUSH(16ビット単位)が使えない」
>>380「使えないわけはない」
>>381「Z80だとバイト単位でのPUSHは出来ないよw」
使える|使えない という話に対して「出来ない」とか言い出した>>381がアフォ >>382
>まー引数を60個近く渡すバカも居ないとは思うが
「引数を60個近く」って何の話?
>6502ユーザーからしたらスタックの1バイトは血の一滴以上だからもったいないっちゃもったいない
貧乏CPUのユーザーの話はZ80は関係ないのでは? いや、35年前の俺なら「貧乏CPU」などとは言うまい。
ファミコンが出るまでは、なんつーの?「ヤナセの外車」のイメージ>6502 車に興味がないので
「ヤナセの外車」という例えがわかりません・・(´・ω・`) 本国の3倍の値段でぼったくる悪徳輸入業者ってイメージしかないなw >>391
ファミコンは、コアが6502互換なだけで、ブツはリコーが開発した、今で言うSoCの走りのようなカスタムチップだったような。 >>383
それならHLをフレームポインタにして
DEC HL
LD (HL),A
の方が良いな。 >>395
バイト単位でのPUSHが出来るかどうかって話でしょ >>395
2バイトのPUSHが混在することは目に見えてんのに馬鹿なの? >>396
バイト単位でのPUSHは出来ないのが明らかで、
それでもコンパイラの実装として、
>>383のようなコードを使う意味があるかどうかの話だと思うけど。 > バイト単位でのPUSHは出来ないのが明らかで、
DCX SP
LXI H,0
DAD SP
MOV M,A
フツーにできるのでは?
> >>383のようなコードを使う意味があるかどうかの話だと思うけど。
・1バイトのPUSHをしたい局面では意味はあるんじゃないの? PUSHができてもPOPができなきゃ意味ないような… コンパイラ的には関数にパラメータ渡すだけなら、PUSH(つーか積むだけ)が実装出来ればよくて
返ってきた後は、SPを戻すのよ。
PUSH 引数2
PUSH 引数1
CALL 関数
LD HL,引数全部のバイト数
ADD HL,SP
LD SP,HL
とか >>402
TL/1のZ80はpascal呼び出しだったかもしれん。忘れた。
PUSH arg2
PUSH arg1
CALL func
次の処理
--
func:
;なんかした後
POP DE ; CALL元をDEに
LD HL,引数全部のバイト数
ADD HL,SP
LD SP,HL
EX DE,HL ; CALL元に返る
JP (HL) Z80ってSPが奇数だと読み書きにwaitが入るんだっけ? >Z80ってSPが奇数だと読み書きにwaitが入るんだっけ?
そう思った理由が知りたい 8086は4クロック(?)追加だからねぇ。勘違いしたのかも。 TL/1 を C のコードに変換するトランスレータくらいなら作れそう。 アホくさ
Cが使える環境があるならCでプログラム組めば? 過去にTL/1で書いたプログラムを生かさない手はない キャリー付き加減算をどうCに変換するかが腕の見せ所 >>415
変数を確保して演算ごとに書換えるよ。
生成する C コードはポータブルなものになるようにする。 かなりのんびりやってるから今年じゅうに出来るかどうかというレベル。
今は文法エラーな入力があったときの報告をちょっとマシになるようにいじってるところ。 REXX は MS-DOS 版とか Linux 版とかもあるじゃろ。 図書館で『I/O別冊 WICS・BASE プログラム集』を借りてくるのがよいだろう。 1981年1月のアスキーに載ってる連珠のコードにバグ見付けたわ。
実際に動かすところまで出来てないから構文上の問題として検出しただけだけど。
ATAITOYAKU プロシージャの中で呼出してる CHOREN プロシージャは引数無しで呼出してるけど、
定義の方では2つの引数を受取ることになってる。
他の号で訂正入ってたりする? 次の号あたりの巻末にちらりと訂正入ってなかったっけ?
TBNに送ればいいんじゃね 田舎なんで図書館にそんなの置いてないし、
アマゾンの中古でも1999年頃のが一番古いくらいか。
古いのもたまにYAHOOオークションに出ることはあるらしい。
今はアスキーって休刊中でしょ? NTBとGAME用の分しか無かった。
ttp://www1.axfc.net/u/3427953
PW: TBN 1981年1月のTL/1と連珠にバグが無い。 1981年1月の47ページに記載。
注意事項: 連珠 1000行の小文字Lと数字の1を間違わないように、NL:=PL バグがないというのはバグについての記載はないという意味かな。
そんでもって1981年1月の47ページに注意事項が書いてあると。 >>433
thx
アルゴリズムの説明はためになる。 >>433
このスレは老眼マンばっかりだと思うから見易いように色調補正してみた
http://www1.axfc.net/u/3428313 >>434
訂正
>1981年1月のTL/1と連珠にバグが無い。 1981年1月の47ページに記載。
1981年1月のTL/1と連珠にバグが無い。 1981年4月の47ページに記載。 NTB=Nakamozu Tiny Basicやね イラストもプロじゃなくて身近にいたちょっと絵が上手い奴に描かせてた >>438
えええそんな、あの毒々しい色がいいのに
つかpdfの方は一応OCR掛けてある。 TL/1連珠の テキストファイルが欲しい。
ASCII 1981/1 ページ164,165 のOCRでもよい。 >>444
http://www1.axfc.net/u/3429099
オリジナルで改行してないところを改行したりしてるけど、
プログラム的に意味が変わるようなことはしてない。 >>445
確認した、ありがとう。
微妙に違っているけれど、大いに助かる。有難う。 一目を表現するのに1バイト必ず必要、ということはないので19道盤も可能 それはそれとして囲碁は「路盤」、連珠は「道盤」って言うんだな。へぇ。 MEM(AD0, Y*15+X):=なんとか
とかやってたのを
SET(X, Y, なんとか)
とかやっても面倒ということはない。むしろスッキリする。 >>429
推測だけど変数 I と BB は大域変数だったのを引数で渡すように変更しようとして直し忘れた感じじゃないかな。
ATAITOYAKU が受取ってる I と BB をそのまま渡せばいいと思う。 C に変換してコンパイルしてみたらまともに動かないなーと思ったら、
FOR 文を単純に置換えたら駄目なことに気付いた。
これを
FOR V:=0 TO 255 DO FOO(V)
↓
for(unsigned char v=0;v<=255;v++) foo(v);
こうしたら無限ループやないか。 スマソ。 >>445 のやつ INPUT プロシージャの中で $61 とすべきところが 61 になってる。 $ が抜けてる。 まだ間違ってた。
メインプログラム中の
MEM(AD0, Y*15+X):=0
は
MEM(AD0, Y*15+X):=B
が正しい。 もうひとつ。
HOUKOU の中の D:=E-(VX[I]*5) は D:=E-(VY[I]*5) が正しい。 なんかもうグダグダだから完全になったと確信したらもっぺん上げるわ ようやく Windows でそれっぽく動く実行バイナリできたぞ。
http://www1.axfc.net/uploader/so/3430543
オリジナルのソースから自動変換のみで C に変換してコンパイルした。 どこのどいつが作成したかもわからん.exeなんていまどき実行する奴おらんだろ 支援するライブラリが整理できてないんだわ。
とりあえず連珠を動かせる分だけはあるんだけどごちゃっとなってる。
変換した分だけあっても動かすところまでは出来ない。 しばらく前に更新してランタイムライブラリも上げたよ〜。
Mingw と Msys と Sagittarius が必要なので準備が面倒かもしれない。
Sagittarius の最新リリースのバグに引っ掛かるので 0.5.9 を使うか次のリリースを使ってね。 >>467
言語というか言語処理系という意味でならそうでもない。
例えば TL/1 が登場した頃のマシンではメモリが 32kB とかの場合もあったわけで、
その範囲内で動くネイティブコンパイラを作ろうと思ったらそれなりに工夫がいる。
だけど今それを再現しようとすると柔軟なプログラミング言語を使って実装できるし、
出力さえ高級言語なので、要するに巨大なシステムに乗っかって楽できる。 GAME や VTL はネット上を探せば資料が見付かるけど、
Kumajiri やマイクロplanはマジ全くと言っていいほど無いな。 インタプリタとコンパイラがある、
単純なインタプリタがTinyBASICがある、
ソース公開されている。"Palo Alto Tiny BASIC"
コードが小さくて読み易い。
しかし 8bitの整数型だと制限がある。
MC68000用のTinyBASICがあって、
32bit整数なので利用範囲も広がる。
現代だと、64bit整数型にすればよい。
コードを読んで学ぶのが良いと思う。 >>472
>ソース公開されている。"Palo Alto Tiny BASIC"
>コードが小さくて読み易い。
>しかし 8bitの整数型だと制限がある。
>MC68000用のTinyBASICがあって、
>32bit整数なので利用範囲も広がる。
>現代だと、64bit整数型にすればよい。
ソース読む以前にPalo Alto〜 使ったことないよね? >>472
>単純なインタプリタがTinyBASICがある、
>ソース公開されている。"Palo Alto Tiny BASIC"
>コードが小さくて読み易い。
コード小さくするために変なテクニック使ってたりして読み易いものでは
なかったがなあ?
つーかオリジナルってミニコン使って独自ニモニックで書かれてて、別の
人がインテルニモニックに書き直したのが複数(東大版とか)あったんでは
なかったかな。 モニタと一緒にROM化された奴ってないのかな?
互換ROM代わりにエミュレータに組み込んであれば遊べるんだけど。 MS-Dos版 tiny BASIC
http://www.mtmscientific.com/PATB.zip
中にある、.com をMS-DOSで動かせば、動く。
機種依存が無い。Windows98でも動く TL-1のいいところを削いだようなコンパイラだったなあ >TL-X _,,;' '" '' ゛''" ゛' ';;,,
(rヽ,;''"""''゛゛゛'';, ノr)
,;'゛ i _ 、_ iヽ゛';, お前それシロピョンにも同じ事言えんの?
,;'" ''| ヽ・〉 〈・ノ |゙゛ `';,
,;'' "| ▼ |゙゛ `';,
,;'' ヽ_人_ / ,;'_
/シ、 ヽ⌒⌒ / リ \
| "r,, `"'''゙´ ,,ミ゛ |
| リ、 ,リ |
| i ゛r、ノ,,r" i _|
| `ー――----┴ ⌒´ )
(ヽ ______ ,, _´)
(_⌒ ______ ,, ィ
丁 |
| | TL-XってTL-1のいいところを削いだようなコンパイラでしたね >シロピョン 高機能化して重くなるんならもちょっとマシな仕様の他の言語選ぶよなあ… 筋の悪いところは多いな。
でも、具体的にもっとマシな他の言語というのが
当時あったのかというと…… 無いんじゃない? 売り物だけどTurbo PASCALとかBDS Cとかかな。 RSA暗号の複号器とかがさくっと作れるような言語ってある? PALLは雑誌投稿プログラムをハドソンが勝手に販売していた疑惑が濃いらしいね。 今からでも検証可能だよ。
まあ出版物とは言え、とっくの昔に絶版になってるし、
手間かけてまで技術的に検証したいって人はそうそういないし、
検証したところでもうどうにもならんし。 PALLはI/O1979年12月号からハドソンの中本氏と竹部氏の連名で寄稿された記事が載っている
よその雑誌に載ったものをI/Oみたいな超メジャー誌に載せようものなら即指摘が入りそうなもんだが
実際には3ヶ月後もまだ連載は続いているし1年半近くあとのハドソンの広告でもまだPALLは掲載されている 疑問の余地なくパクりだよ。
ただ、当時はそれが許されるほどではなくとも大きな問題にするほどでもない程度のことだったってこと。
今の価値観で見ても意味ない。 >>491
マイクロplan
http://www.pro.or.jp/~fuji/computerbooks/pasocom/micro1978.bit.html >>492
その本の112頁から引用
> マイクロ Plan はその名のとおり, ミニコン用のミ
> ニ言語である Plan 系のマイクロ言語である. ここで
> は, マイクロ Plan および その 8080 用システムである
> マイクロ Plan/8080 について紹介しよう.
マイクロPlanはミニコン用ミニ言語Planのパクリ。 当時はその程度のパクりは許容されていたし、
現在でも言語仕様を元に別の実装を作るのは不法ではない。
ただ、 PALL に関しては実装を丸パクりしていたということが問題。
これは著作権の侵害にあたる。
ダンプリストの形で掲載されていたのでわざわざ検証するという手間をかける奴が
すぐには現れなかったとしても不思議ではない。 根拠もクソもコンパイラの実装がかなり似通っているとしか言い様がないんじゃね。
同じ仕様を実装すれば同じようなものになるのは道理であるから言い逃れの余地はあるけども。 機械語とかさっぱりなので、直接双方のコードを比較できないのだけど、
WikipediaのMZの項目 ttp://ja.wikipedia.org/wiki/MZ_(%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF)#cite_ref-12
のネタ元になっているところ ttp://o-ta-su-ke.net/7652.html#comment-521417 では
「エラー表示関数以外の部分はコンパイラの16進ダンプリストが全く一緒だったんで」
とある一方、I/Oの1980年1月号「PALLを解剖する![1]」では
「このコンパイラは、構造的にはμPLAN(TM)^1)とPL/0^2)のコンパイラを基本としていますが、
μPLAN(TM)では、Pコードオブジェクトがリロケータブルではないので大幅に変更して、
どこのメモリ空間でも使えるようにしてあります。
また、PEEK、POKE、CALLの機能を付加して、強力なコンパイラにしました。
(中略)
■参考文献
1)マイクロコンピュータのプログラミング、bit増刊号
2)アルゴリズム+データ構造=PASCALプログラム、コンピュータ協会」
とある。このふたつの記述は両立するのか、それとも少なくともどちらか一方は不正確なのか? どっちかが間違い(あるいはウソ)だろうな。
>「エラー表示関数以外の部分はコンパイラの16進ダンプリストが全く一緒だったんで」
が本当ならそんな機能強化はできないはず。 >>492の本の記事 戸村哲『マイクロPlanのプロセッサ』にダンプリストなんて
載ってない。
「マイクロPlanコンパイラ」はマイクロPlanで書かれたソースとRコード(ASCII
キャラクタによる中間言語)掲載。
「マイクロPlan/8080 Rコード・ローダとQコード・インタプリタ」はアセンブル
リスト掲載だが、開始番地が0B00Hなので、0000〜0FFFまでROMが配置されてる
MZではそのままでは実行不可能。
「コンパイラの16進ダンプリストが全く一緒だった」が何を言いたいのかわからん。 後続する文章から「ダンプリストを逆アセンブルして比較検証した結果が一致した」という意味だと思うが。 アドレスが同じになりようがないので「全く一緒」がありえない。
投稿者が一方的に言ってるだけで信じる気にもならんな。 「逆アセンブルした」という文があるんだから
アドレスまで一致していたという意味じゃないのは明らか。 >>498によると参考にしたことは明記してたみたいだし丸写しとかありえんだろ
ネットでよく見かける思い込みの激しい馬鹿のイチャモンに見える >>503
>エラー表示関数以外の部分はコンパイラの16進ダンプリストが全く一緒だったんで ダンプリスト一緒=コードが一緒
エラー表示関数以外は丸パクリってことだろ? ダンプリストが違うのだから、類似であるが別物である。
同じだと言い張るのならば、両方の全ダンプリストを提示しなさい。 本当か嘘か判断できない話があったとして、
ttp://o-ta-su-ke.net/7652.html#comment-521417
その話を主張してる奴が馬鹿っぽければ嘘と思ってて良い。 /.⌒ヽ
/ .\
../ ヽ. \
(./ ヽ. )
i r-ー-┬-‐、i
| |,,_ _,{| やらなイカ?
N| "゚'` {"゚`lリ
ト.i ,__''_ ! いいこと思いついた
/i/ l\ ー .イ|、 おまえオレの中にご飯詰めろ
. 丿ノ ノ 丁丁 ̄l\
. く_(__(_(_._」____)ノ >>504
著作権での保護は派生物にも及ぶ。 丸写しでなくても、参考元を明記しててもそれでよいというわけではない。
個人的利用ならともかく商品にするのにμplanのコードを (全てではなくとも) 許可なく使っちゃ駄目。
厳密なことを言えばクリーンルーム設計のような手法が求められる。
が、当時としてはライセンスを厳密に運用しないのが業界慣行であったのは確かで、
後付けで何を言っても意味ないし、そもそももうハドソンという会社は無くなってるしな。 >著作権での保護は
日本でコンピュータプログラムが著作物として認められたのいつだか知ってて
こんな馬鹿なこと言ってる? 参考なら関係ないのよ、丸写しなら影響があるけれど。
サブルーチンなどは同じものがフリーで流通してるしちょっと似てるからと言うだけで意味不明だな
いつの時代の話をしていのか? TinyBASICの時代だろ、雑誌公開がフリーと言われてる時代 >>511
だから「当時としては」と書いてるじゃん。
当時の運用実態としては見逃がされていたのは知ってるっつーの。
最初に認めたということはそれ以前には無かったということにはならない。
条文として明記されたのは昭和60年だけど、
昭和54年の事例でソフトウェアは著作物であるという判例があるわけで、
改正前の法でもソフトウェアは著作物だった。
問題になって裁判まで起こした事例がそれまで無かったからそれ以前は合法だったというわけではない。 >昭和54年の事例でソフトウェアは著作物であるという判例があるわけで、
1978年に出版された本で発表されたμPlanと何の関係がある話ですか?? >>514
その時点の法律でソフトウェアが著作物であるという判断が下せるという根拠。
たまたま最初に裁判になったのが昭和54年であるが、それ以前からソフトウェアは著作物であった。 >>515
お前が「法の不遡及」も理解してないことは分かった。 わかってないのはお前。
法の制定前まで遡って違法として処罰することを禁止するのが不遡及の原則であって、
当時においても違法だった (ただし判例は存在しなかった) という話をしてんだよ。 プログラム言語は著作権ではない、言語仕様は著作権に含まれない。
まったく同じでないのならば、それは別物です。 >>517
分かってないなw
著作権法での著作物の定義にプログラムが含まれていなかったので条文化される
以前は一般にプログラムは著作権法でいうところの著作物ではなかった。
ある判例が出たところでその解釈が他のプログラムにも該当するかは判断は別。
その判断がないところで判例以前のものに遡って適用されることなどない。 そもそも通産は何故通商貿易と産業振興が一緒なの?
どう考えても利益が対立しそうだけども。 経済金融まで引き連れてこられたら、産業に勝ち目ないじゃん。
銀行から乗り込んで来たコストカッターの言いなりじゃデフレにもなるよ。 >>520
> 文部と通産が争って、文部が勝ったのが日本の不幸
そうそう
物作り立国だの理系教育だの言っても
メインストリームは文系だから
何にも出来ないんだとさ 科学技術省に国鉄と電電公社と郵便局くっつけたら無敵だったんじゃね? 「コンパイラの16進ダンプリストが(相対ジャンプなどを除けば)全く一緒だった」
とすればわからんこともない。
実際に一緒だったかは知らん。 >>528
大雑把に言うと、
アセンブラだと「開発環境に必要なリソース」と「実行環境に必要なリソース」のバランスが悪い
んだと思う。
当時はCP/M上で動くスクリーンエディタ+リロケータブルマクロアセンブラ+リンカ+シンボリックデバッガ
なんて高嶺の花なわけで、
テープベースでメインメモリ8KB〜最大48KBみたいなプアな環境の中でハンドアセンブル(マシン語直打ち)
よりもマシなプログラミング環境を求めるとTINY言語になってたんじゃないかと。 >>529
だからシナジー効果高いんじゃないか。
全部ロボット化するくらいの勢いで。 >>532
自動化なんかしたら首切りが始まるってんでストばかりになるだろ。
なに言ってんだ。 >>67
ようやく資料を手に入れた。
「熊谷、池尻両女史」とあるけど、誰なのかはわからん。
当時 I/O を読んでた人ならわかるの? 僕が伝えたかったこと、古川享のパソコン秘史 を読んだら巻末に登場人物の
その後の話とかがまとめて載っていたのだけど、大西博氏は GAME と TL/1
の作者としか書いてなかった。やっぱり謎の人物だなあ。 K-Compiler というか K言語の仕様を知りたかったらどの雑誌のどの号を読めばいいの? 最初のKコンパイラはI/Oの1982年3月号にFM-8、L3用が掲載された
全8ページの記事で半分の4ページが説明文で半分の4ページがダンプリスト
なので、言語仕様もわずか4ページの説明文の中に書かれている
その後に改良版やら拡張版から移植版やら色々出たけど
その度に言語仕様が書かれていたのだろうか? FM-7/8活用研究には拡張版のダンプリストがあるけど、
1ページ半くらい言語仕様が書いてある。 KコンパイラってSYS-9の後継みたいな感じだったな。
SYS-9と言えば、PSKのロリータIIがこれで書かれていた。 GAME-MZ の載った ASCII も持っていた気がしたのだが見つからず。
あとは S-OS の FuzzyBASIC、SLANG あたりは掲載誌持ってるんだけど
仕様自体はネットに上がってるかな? K Compiler のコメントは Pascal タイプなのですな。
言語仕様の単純変数例がw
熊谷、池尻女史に次いで三浦女史? >>546
FORM の資料はもっと高解像度のものが Internet Archive から入手可能なので、
色調だけ補正してみた。 印刷しても見やすいと思う。
https://www.axfc.net/u/3812412.zip
ダウンロードパス&ZIPパスワード eb3dcaf22c4c716d04bdc6c7ebfa6fbd >>545
K は基本的なライブラリは機械語のサブルーチンを読みだす前提っぽいな。
まあ当時としてはそんなもんか。 BASIC一行エディタでソース編集して機械語ジャンプでコンパイル/実行では無理があるな。
kコンパイラはコード生成や仕様はともかくOS上の動作は必要だろう。
OS為しの組み込み用PL/Mですらホスト上でコンパイルするクロス開発なので。
当時のTiny言語は例外なく最大変数型はshort intのみだが、これはCPU命令に依存した実装のためだろう。
本来8bitはcharを複数個並べてlongなど処理するから実用上ソフトマクロは必ず必要。
i4004は4bitのBCDで8桁電卓の演算するからね。ハードは安くソフトに依存するからライブラリは必須だよ。 以前に TL/1 で書かれた連珠について投稿したけど、
あれは全部 TL/1 の言語仕様の範囲内でやってたな。 PICO-8 とか、それに触発された TIC-80 などの Fantasy Console (または Fantasy Computer) というカテゴリが近頃は隆盛らしいけど、
このスレ的にはそういうのは無し?
まあそういうのはだいたい Lua とかを採用してたりするから、独自の言語というわけじゃないが、
これからそういうのが発生した場合に。 >>555
>以前に TL/1 で書かれた連珠について投稿したけど、
>あれは全部 TL/1 の言語仕様の範囲内でやってたな。
細かい事を言うと、TL/1 オリジナル言語仕様には
IF〜THEN構文で ELSE が使えない。(CASE構文専用)
TL/1-PC用の連珠では IF〜THEN〜ELSE 使ってる。
TL/1-FM では、MEMのアドレス変更だけ、
TL/1-L3 では、MEMのアドレス変更と IF〜THEN〜ELSE 対応修正
をして、動作させる事ができた。 dl-pass/解凍pass=「not-kumajiri」
https://www.axfc.net/u/3902054.zip
あと、解凍&実行等は自己責任で。 2時間くらいしたら、>>563でupしたモノを消します 《 Windows7後継開発環境のご案内 》
LinuxMintのダウンロードはこちらから。
Main Page - Linux Mint
https://linuxmint.com/
https://linuxmint.com/download.php
---------
AGK無料試用版の配布開始(リンク先にWindows、Mac、Linux版のファイルが直接置いてある)
AppGameKit - Free Trial Version
https://www.appgamekit.com/trial
無料試用版
AppGameKit無料トライアル版は、AppGameKitの主要な領域すべてにアクセスできるため、
完全に評価することができます。完全版の有料版には、次の主要機能が含まれています。
・ Android、iOS、HTML5にプロジェクトをエクスポートする
・ アプリをデバイスに直接ブロードキャストする
・ コンパイルされたプロジェクトからウォーターマークを削除する >>558
どちらかというと古いCHIP-8のほうがこの場所的な話題になると思う。
PICO8は教育向け製品のように思う。
>>564
それは何ですか? >>566
CHIP-8 って現代の感覚からいうと言語っていうより仮想マシンじゃね?
それと >>564 は拡張Kコンパイラとそのドキュメントだったよ。 CHIP-8 がターゲットのプログラミング言語ってあるの? CHIP-8だけをターゲットにするなら、この板の範囲外じゃね? 今の技術でTINY LANGUAGE作るとすれば、どんな仕様になるだろうな? >>570
前提とするマシンも現代のものという前提で? >>571
そう。当時の乗除算もない貧弱なCPUに比べれば、今のCPUは機能豊富。同じ2K、4Kでもできることが随分広がるかも。 インタプリタなら Lua が決定版でしょ。
ネイティブコンパイラを Tiny にデザインするとしたら、
PALL みたいな言語を C 風の記法に寄せるくらいじゃね。
コンパイラの実装面では工夫できることは多いと思うけど、
言語自体はそれほど極端に変える必要はないでしょ。 >>572
動作環境を現代のコンピュータと仮定するなら CRT こそフルセットでもいいでしょ。
要するに「どうせあるもの」なんだから、使わなきゃ損。 >>573
ゴールの設定によるかも。
大きいプログラムをある程度の小さい規模に落とし込むプログラミング言語 (処理系) は需要があるにしても、
小さいプログラムをギリギリまでリソース消費を抑えるのはそれほど需要がないし、意味がない。
潤沢なマシンリソースをある意味では「無駄にしている」ことになるわけだし。
「趣味的な面白さ」を軸にするのだと主観的なものになっちゃうから、
昔よりずっと自由度の高い前提の上だと人によってかなり違う意見になっちゃうんじゃないかな。
これは面白いって皆が言うようなタイニー言語はもう生まれないんじゃないかな……。
ちょっと寂しい話だけど。 micro-Pascalって有ったな
TinyだかBaby AWKも有った
micro PythonはCP/Mには無い? Python の文法自体は簡素だからフルセットの機能を要求しないなら
CP/M 級の環境でも Python っぽい処理系を作れないことはないんじゃないのかな。
まあやろうとする人がいるとも思えないが。 パーサー処理て実装難しいからパーサー必要ない言語があると面白いとは思う。
RPNなForthや電卓記号言語のようなものかな。
マトモなパーサー処理せずにAWKでパターンマッチング繰り返してバイナリ生成
していた古いFORTRANのような処理系があったらそれはそれで面白いし
プログラミング言語ではなくシーケンサーという条件なら子供でも理解できて
処理も単純化できそうだが。 Brainfuck とかか?
https://ja.wikipedia.org/wiki/Brainfuck
コンパイラのサイズはわずか123バイト、インタプリタは98バイトであった。 構文解析は言語処理関連の中ではかなり理屈が確立されてる部分だから、
面倒くさいけど難しいってほどでもない。
なるべく単純な文法を設計するに越したことは無いけど、
実装を楽しようとして言語デザインが実装方法に引きずられ過ぎるのも不格好だと思うなぁ。
このスレの趣旨からすると好事家が遊べれば充分だが、
多少は使い物になることも考えようよ。
Forth くらいに突き抜けてたらそれはそれで面白いし実務的だけど、
Brainfuck は余興にしか使えんでしょ……。 forthの式は逆ポーランドだが手続き型なのでステートメントはjavaのように構文を書く。
中間言語インタプリタなので遅いし飛び抜けて実用的とは思わないな。
元々の機械動作は可読性と関係ないから小型化しようと思えば人が理解可能な可読的要素は
一切ないと思った方がいい。VTLなどのように記号言語のようになる。
最初から可読的言語デザインよりはエディタやデバック支援環境がある方が便利だと思う。
支援環境側で記号的難解言語の可読性の支援をするほうが言語レベルのサイズは小さくて済む。
言語サイズはBrainfuckくらいがちょうどいいと思う。 Excelで懐かしい手書きコーディングシート形式のワークシート作った。
セル幅変えてそのまま枠線出力する。
タイトルにFACOMとかUNIVACとか入れると一層良くなる。
COBOLやFORTRAN用。 位置が決まってるタイプの言語だとエクセル (表計算ソフト) でコーディングするのは良い案だと思う。 >>557 ありがとうございます
FORMはMZ-1500のQD対応に改造されていました コロナ禍が治まったら、図書館にTL/1の資料でも
探しに行こうかな。 スレが立ってからはや20年。これより古いスレが90くらいあるのは過疎板ならではですな。
TL/1やGAMEの作者の大西博氏ですが、亡くなられていたようです。
https://www.sophiakai.gr.jp/news/news/2020/2020082501.html
上智大の講師らしいという話がTwitterであり、年齢的にも合っているように思います。
ご冥福をお祈りいたします。 ソニーのアセンブラのANN表記についてきちんとした仕様はネット上のどこかで見れたりします?
概要とか紹介みたいな形で部分的に雰囲気はわかるんですが、
仕様を網羅したものは見つからないみたいで、どうにかして当時のリファレンスマニュアルを手に入れるしかないんですかね? http://jump.5ch.net/?http://www.win-corp.jp/etc/msx/
ミニ言語らしい イイネ!
でも SLANG と比較して特によくなっているという印象はないので
なんらかの差別化要素があればもっとよかったかもね。 >>597
Oh! X の 1990 年 1 月号 (146~149 ページ) にあるリファレンスマニュアルが完全な仕様だと思う。
https://archive.org/details/OhX_1990-01/page/n147/mode/2up
前後の号で使用例もあったはず。 さんきゅ 面白かった。
Windowsに実装されていたら、まだ子孫がいたかもね。 SLANG の文法を形式的な表現に書き直してみようと試みたら若干の不明点を見つけた。
・ アドレス宣言、大域宣言、関数は順不同でもよいのか? (関数定義の後ろに大域宣言があってもよいか?)
・ 変数名として使える文字は? (名前の先頭以外に数値を含むような C ならアリなパターンは許容される?)
・ 定数式とは何か? (C の定数式は割とめんどいので SLANG がそのレベルを要求してはいるはずはないだろう……)
・ 大文字と小文字は区別するか?
当時の事情の中では自明だったりするんかな? Windows 版があったけど Bad File Descripter とでてコンパイルできなかった。
ファイル形式がわからんー
SLang Compiler ver 1.00
]D
Asc Q:a .txt:0000:003C:0000
Asc Q:cygwin1 .dll:0000:FFFE:0000
Bin Q:EMATE .obj:3000:3CA2:3000
Asc Q:readme .w32:0000:07E4:0000
Bin Q:SLANG .obj:3000:730C:3000
Asc Q:sos .exe:0000:FFFE:0000
Asc Q:sos .ini:0000:005F:0000
Nul Q:source . :0000:FFFF:0000
Bin Q:sword .bin:2100:2AFF:2100
]C a
File not Found
]C a.txt
Bad File Descripter
] a.txt こんな感じだと思うんだけどうまくいかない。
ORG $8000;
MAIN()
BEGIN
PRINT("hello");
END; S-OS には Windows 版があったのか……。 ちょっと興味あったので探したらここのアーカイブにあるやつかな?
UNIX版のソースがあったのでコンパイルしてみたけど24行決め打ち
しているぽくてsegmentation faultしたw
http://www.retropc.net/ohishi/s-os/ MSX3が出たら、tiny系の言語も楽しめるだろうか。 あの手の小さな言語は細々としたところは低レイヤを触らせる前提だったりするから移植性があまりなくて、
言語自体に興味があっても実行環境 (エミュレータでもいいが) を保全するのが面倒になるんよね。 この手の言語は16ビット世代には移行しなかったな。 このチマチマしているやつと、オブジェクト指向で湯水のようにメモリ使うやつの中間が欲しい。
あたらしいMSXでは何か提案あるだろうか。 チマチマと湯水の間が「ただの」C言語とかじゃねーの