はげあたま.org

*

SHENTHEN I/O裏仕様についての基礎的調査

   

一昨日の記事は1万人以上に読まれたようで、少なくとも数十人は深センへの出稼ぎ組が増えたのを確認しております。

さて、今日はそんな中でもコストを削っている組へ向けての検証です。
ここまで感覚的にやっていましたので、色々とテストしてみました。 アルゴリズムというよりは、ゲーム仕様側のお話です。
組んでる人には伝わると思うので端的に書いていきます。

ディープすぎるし、多少ネタバレもあるので未プレイ組はお帰り願います。
あと、現時点で私自身がMC系チップ以外の非推奨部品を使用してないので、そちらは使い方もわかってません。あしからず。

 

チップの違い

MC4000とMC6000で同じコード走らせると消費電力そのものは変わらない。
物理的には違和感あるが、コードゴルフ的にはやりやすい気もする。

 

ケーブルの長さ

消費電力への影響無し。迂回させても微塵も変わらず。ブリッジもいくら使っても影響無し。

 

accとdat

消費電力的には振る舞いは変わらず。

 

addとmul

 

スクリーンショット (152)

かなり違和感あり。
皆が”mul 2″で解いたであろうこの問題。加算の”add acc”にすれば乗算より削れるのでは!!?と天啓が降りてきたものの不発でした。全く同じです。

 

accへのアクセス

mov 100 acc
mov acc p1
slp 1

 

mov 100 acc
mov 100 p1
slp 1

ちょっと意外な結果。両者は消費電力的には等価らしい。
変数へのアクセスを必死に直接指定で置き換えられないか試行錯誤していた昨日までの俺の努力は……

 

nullと100と999

simple I/O、xbusともに出力があればそれがnullだろうが最大値だろうが消費電力が一緒。結構重要な知見かと。
これも想定外で、今まで必死に渡すフラグは小さい値に揃えようとしてたけど、むしろ3桁渡してdgt判定などの余地を作った方がいいってことかも。

 

条件式

スクリーンショット (173)

teq, tgt, tlt, tcp、全部変わりません。意外なようなそうでもないような。

 

nop

何もしない命令のくせしてxbus使い出すと非常に便利なnopさん。
てっきり本当に何もしないとかと安易に使ってたら、1個で60powersも消費してんぞ(゚Д゚)ゴルァ!

 

2系統以上のxbusの合流

スクリーンショット (163)

 

スクリーンショット (164)

 

見た目に違いはないんだけど、どうも配線関係なく設置位置により、下側→左側の優先度でシーケンシャルなステップが入るっぽい。(未確認)

1回目の入力で63→37→0で直接入れて判定してるけど、1枚目だと下2つが走った後、上が走る。
一方、下にnopが入れると上→下の順となる。

結構クセがあるし(こんなもんなの?)、3つだとさらにカオスなので説明しづらい。各自で試して身体で覚えましょう。

 

2系統以上のsimple I/Oの合流

これはシンプル。よーいどんで一番大きい数値が最終的な出力となります。2系統分の加算などは無し。

 

おわりに

未プレイ勢どころか、低コスト化目指してない人には何のこっちゃって話ばかりかもしれません。
ガチ勢には「え、これだけ?」という人もいるでしょうが、この辺りは基礎的ながら重要な示唆がいろいろと含まれてると思いますよ???

検証内容が思いつくたびに、ちょくちょく追加していく予定です。

 

追記:実際に競っているのは「ステップ数」だと教えてもらった。なるほど、しっくりくる。

 - ゲーム, 開発