iizukakの作業ログ

忘れる前にメモしよう

Cloud Build で macOS/Windows アプリケーションをビルドする

環境

  • Unity 2018.2.10f1

はじめに

Unity 用の CI 環境がほしいと思って Cloud Build を試しています。まだ少し触っただけなのですが、非常に便利そう。数クリックで macOS/Windows 用のアプリケーションをビルドして、ユニットテストまで実行できる…。 今のところは基本的には有償で、月 9 ドルで 25GB のストレージがついてくるようです。Unity で CI やるにはオンプレでそれなりにコストをかけてやる (MacWindows マシンに Jenkins なり CI サービスを立てたりする) ことが多いと思うのですが、フルマネージドで 9 ドルというのはめちゃ安いと思うんですよね。

リポジトリ

こちら のテスト用リポジトリで試しています。

Cloud Build の使い方

Cloud Build の UI はそれほど複雑ではないので、直感的に操作することができました。最終的な設定結果は次のようになっています。

f:id:iizukak:20180929224709p:plain

私は普段 macOS で開発を行っているので、Git の master ブランチが更新されると、macOS 用のビルドが自動的に走るようにしています。またこの際にユニットテストも自動的に実行し、テストに失敗した場合にビルド全体が失敗するようにしています。Window については時々しか確認しないし、ディスクスペースももったいないので自動ビルドは切ってあります。

リポジトリ追加

リポジトリの追加については、Github や Bitbucket といった GIt のホスティングサービスを使うか、Git リポジトリをマニュアルで設定するか選べます。今回は Github 上にあるリポジトリをマニュアルで設定していて、次のようになってます。

f:id:iizukak:20180929225117p:plain

リポジトリを追加すると公開鍵が表示できるようになるので、これを Github リポジトリの設定で Deploy Key に追加します。これで Cloud Build からリポジトリにアクセスできるようになります。

Target 追加

macOSWindowsWebGL などを Target として追加でき、Target ごとに細かく設定ができます。

  • 自動ビルドするか
  • どのブランチをビルドするか
  • テストを実行するか
    • EditMode テスト
    • PlayMode テスト

等の設定が可能です。

Unity のバージョン

最新の Unity バージョンが利用できます。新しいバージョンの Unity がリリースされると、48 時間以内に Cloud Build でも使えるようになるようです。

Test Runner で MonoBehaviour を継承していないクラスをテストする

環境

  • Unity 2018.2.10.f1
  • macOS 10.13.6

リポジトリ

こちら にコードがあります。

概要

Unity で MonoBehaviour を継承していない素の C# クラスをユニットテストした記録です。ハマりどころとしては、スクリプトのあるディレクトリで Assembly Definition を追加し、Tests ディレクトリの Tests Import Settings の References に追加する必要があるところでした。

テストディレクトリの追加

メニューバーの Window -> General -> Test Runner から、Create EditMode Test Assembly Folder を追加します。

f:id:iizukak:20180929134708p:plain

Tests ディレクトリができるかと思います。

テスト対象スクリプト

適当なテスト対象のスクリプトを書きます。ここでは単純に 2 つの int の和を計算する静的メソッドを定義しておきました。Assets/Scripts/MyAdder.cs として、

public static class MyAdder
{
    public static int Add(int x, int y)
    {
        return x + y;
    }
}

次に、 Create -> Assembly Definition で、適当な名前で定義を追加します。ここでは ScriptsAssembly という名前で追加しておきます。

f:id:iizukak:20180929220258p:plain

テストスクリプト

テストスクリプトの追加は、Create -> Testing -> Test C# Script で追加します。

Tests/Editor/MyAdderTests.cs

using UnityEngine;
using UnityEngine.TestTools;
using NUnit.Framework;
using System.Collections;

public class MyAdderTests
{
    [Test]
    public void MyAdderTestSimple()
    {
        Assert.AreEqual(MyAdder.Add(1, 2), 3);
    }
}

Tests/Tests というファイルのインスペクタに、定義したアセンブリを追加します。 こんなかんじになります。

f:id:iizukak:20180929215604p:plain

テスト実行

Test Runner でテストを実行します。以下の画面のようになるはず。

f:id:iizukak:20180929215734p:plain

分かってしまえば難しくないですが、どうもググる力が足りず少し時間をとられました。

macOS への SDL 2 のインストール方法

環境

SDL 本体

SDL は本体と SDL_Image や SDL_ttf といった周辺ライブラリが分離されていて、必要なライブラリだけインストールできるようになっています。まずは SDL 本体から。

インストール方法

インストールには二種類あって、ドキュメントでいう "the Unix way" と "SDL.framework" があるのですが、これは Unix Way の記事です。

自分の環境では、SDL公式ドキュメント の通りでインストールできました。まず SDLダウンロード して、適当な場所に解凍したあと、

$ mkdir build
$ cd build
$ CC=../build-scripts/gcc-fat.sh ../configure
$ make
$ sudo make install

で完了です。

動作確認

コンパイル時に必要となるフラグですが、 sdl-config というコマンドが同梱されていて、このコマンドで調べることができます。便利。ビルド時に作った build ディレクトリで、

$ ./sdl2-config --cflags --libs
-I/usr/local/include/SDL2 -D_THREAD_SAFE
-L/usr/local/lib -lSDL2

です。

試しにサンプルコードをコンパイルしてみます。

// Example program:
// Using SDL2 to create an application window

#include "SDL.h"
#include <stdio.h>

int main(int argc, char* argv[]) {
    // Show SDL Version
    SDL_version compiled;
    SDL_version linked;

    SDL_VERSION(&compiled);
    SDL_GetVersion(&linked);
    printf("We compiled against SDL version %d.%d.%d ...\n",
           compiled.major, compiled.minor, compiled.patch);
    printf("But we are linking against SDL version %d.%d.%d.\n",
           linked.major, linked.minor, linked.patch);

    SDL_Window *window;                    // Declare a pointer

    SDL_Init(SDL_INIT_VIDEO);              // Initialize SDL2

    // Create an application window with the following settings:
    window = SDL_CreateWindow(
        "An SDL2 window",                  // window title
        SDL_WINDOWPOS_UNDEFINED,           // initial x position
        SDL_WINDOWPOS_UNDEFINED,           // initial y position
        640,                               // width, in pixels
        480,                               // height, in pixels
        SDL_WINDOW_OPENGL                  // flags - see below
    );

    // Check that the window was successfully created
    if (window == NULL) {
        // In the case that the window could not be made...
        printf("Could not create window: %s\n", SDL_GetError());
        return 1;
    }

    // The window is open: could enter program loop here (see SDL_PollEvent())

    SDL_Delay(3000);  // Pause execution for 3000 milliseconds, for example

    // Close and destroy the window
    SDL_DestroyWindow(window);

    // Clean up
    SDL_Quit();
    return 0;
}

main.c というファイル名で保存して、 sdl-config で調べたオプションを追加し、

$ gcc -I/usr/local/include/SDL2 -D_THREAD_SAFE -L/usr/local/lib -lSDL2 main.c

コンパイルできます。実行すると、SDL のバージョンが出力されると思います。その後ウィンドウが作られ、3秒後に終了します。

$ ./a.out 
We compiled against SDL version 2.0.8 ...
But we are linking against SDL version 2.0.8.

SDL_image

画像を扱うときに使うライブラリです。こちらも 公式ドキュメント そのままにインストールすることができました。

SDL2_image-2.0.3.zip を DL して適当な場所に解凍し、

$ ./configure
$ make
$ sudo make install

でオーケーです。

SDL_ttf

SDL でフォントを扱うライブラリです。こちらはインストールに freetype が必要なので事前に homebrew でインストールしておきます。

$ brew install freetype

それ以外は 公式ドキュメント 通りでインストールできました。すなわち、 SDL2_ttf-2.0.14.zip を適当な場所に解答して、

$ ./configure
$ make
$ sudo make install

でオーケーです。

Maker Faire Tokyo 2018 で、"ピクセル化装置" を展示します

なにか

Maker Faire Tokyo 2018 で、ピクセル化装置というものを展示します。何なのかというと、 Raspberry Pi で、 Web カメラの画像を、 LED マトリクスにリアルタイムで表示する装置です。

装置の詳細

Github に記載してあるのでそちらを御覧ください。

どこで見られるか

Maker Faire Tokyo 2018 の KLab Make 部 にて展示します。位置は H09-04 です。ぜひふらっと起こしください。

なぜ作ったか

世の中のディスプレイはどんどん高精細高密度になってきて、最近のスマホや PC だともうピクセルは見えません。そういったご時世に、あえてピクセルを意識させるような装置を作ったら面白いかもな、ということで作ってみた次第です。動画だとあまりわかりませんが、実際はビカビカしています。

ディジタル回路設計とコンピュータアーキテクチャ[ARM版] 翻訳誤り一覧

いわゆる「ハリス&ハリス本」の ARM 版 の評判が良いようなので読んでみました。組み合わせ回路と順序回路の解説から始まり、HDL の導入、ARM のマイクロアーキテクチャの紹介、HDL を用いたシングルサイクルの ARMv4 サブセットの実装と実に盛りだくさんの内容になっています。私は HDL を全く知らない状態で読み始めたのですが、特に詰まるところ無く読み進められました。このような素晴らしい書籍を日本語で読めることに対して、翻訳者の皆様に感謝致します。

ところで、このような専門書にはありがちなことだと思うのですが、本書にも多少なりとも誤訳が含まれているように思われます。ここに自分が違和感を感じた箇所を掲載しておきます。私のミスリードもあるかと思います。ご容赦ください。

p.2

薄い灰色示している

薄い灰色で示している

p.4

…数を表現するかを論じる

日本語として違和感

p.59

Qにはその否定

~Qにはその否定

p.125

コードに「SystemVerilog」という文字列があるが不必要

p.169

コンピュータで稼働するすべてのプログラムは、同じ命令セットを使っている。

「あるコンピュータで」でしょうか

オペランドはメモリから来る場合や、レジスタから来るか場合、あるいは命令自体から来る場合もある。

日本語に違和感。「来るか場合」>「来る場合」

命令を機械語(マシンランゲージ)と呼ばれる形式に符号化される。

符号化する

p.170

通常的ではない

日本語として違和感

人間が読み易くした

人間に読み易くした

命令が実施する演算

演算を実施するというのは一般的な用法か?

p.172

一時変数s

「s」?

p.181

であるという点で普通でないのが、関数からの戻りは〜

訳に違和感

p.183

siddofsums

diffofsums の間違い?

p.185

怖されれる

壊される

p.193

テクスト

テキスト

(SP)スタックの

(SP)をスタックの

GCC基づいている

GCCに基づいている

p.196

リテラルプールを作った

使った

p.201

備える、

備える。

p.204

表6.19

表6.19が何ページに記載されているのか分からなかった

FB08 CPU 製作記 [03 - データフロー図]

それほど進んでいないのですがメモしておきます。まず、現状のデータフローを図に書き起こしました。それが以下です。

f:id:iizukak:20170115153728p:plain

先週からいくつか差分があります。

  • SHIFTR, SHIFTL 命令を廃止しました
    • IC 数を減らす(アキュムレータのバスドライバがなくて済むようになった)のと、コントロールシグナルのピン数(16)がカツカツなので消しました。CPU の命令としてビットシフトできなくなってしまいますが、これはアキュムレータ自分自身の値を足すことで左シフトはできるのでどうにかなるといいな…というかんじ。右シフトをどうするかは要検討。
  • 論理演算命令を追加しました
    • AND, OR, XOR です
  • オペコードを 5bit にしました。
    • 先週までオペコードは 4bit でしたが、1bit 増やしました。これは、単に命令が 16 種類より増えてしまったから。また、SRAM のアドレスが 11bit なので、プログラム ROM のアドレスも 11bit にしてしまったほうが扱いが楽かなというのもあります。

74HC181 が届きました。

f:id:iizukak:20170114143138j:plain

まだまだ設計段階なので少し先走った注文でしたが、こうやってパーツが届くとやる気が少しアップするので、良いです。

以上です。地道に進めます。

FB08 CPU 製作記 [02 - 大雑把な設計]

前回に引き続き、FB08 CPU の設計について。

設計の進んだ分をメモしておきます。

  • データバス幅を 8bit とした
    • 前回までは 4bit 幅にしようと思っていましたが、8bit にしたところで言うほど回路の複雑度が増さない & IC 数も増ええない & 8bit にすると実装できるプログラムの幅が大幅に広がるため、8bit 幅とすることとしました
  • ALU に 74HC181 を使用することにした
    • eBay で 74HC181 のデッドストックが 出品されていた ため、購入しました。もともとは EEPROM を使ったルックアップテーブル方式で ALU を構成しようと思っていましたが、変更になります
  • プログラム ROM として、29F1615 を使用することとにした
    • 若松通商MX29F1615PC-10 という EEPROM があるようで、これが 1word 16 bit なのでプログラム ROM を収める ROM としてちょうどよい(最長の命令フォーマットを 16 bit にしようと思っていたため)
  • 命令デコーダにも 29F1615 を使うこととした
    • 命令デコーダ論理回路で組むのが本筋なのでしょう。しかしこれが面倒なので、 EEPROM で作ってしまうことにしました
  • 1オペランド方式の CPU とすることにした
    • 最近の CPU ではなかなか無いとおもいますが、 1 オペランド方式とします。ひとつに CPU の簡素化のため、もうひとつにデバッグの容易さのためです。 自作アーキテクチャ CPU 一号機ですし、バグがふんだんに盛り込まれていることは確実です。ですから、CPU そのものも、CPU の上で動くプログラムもどちらもデバッグしやすくなければいけません。ロジック IC で作る CPU では、デバッグというと LED を光らせるとか電圧を測定することになります。1 オペランド方式の CPU の場合、様々な値がアキュムレータを経由することになるため、アキュムレータの値を LED に表示しておけば、デバッグが楽であろうという目論見です

命令フォーマット

命令のフォーマットを、以下の 3 つとします。

1: Addressed
[OPCODE 4bit][ADDRESS 12bit]

2: immediate
[OPCODE 4bit][IMMEDIATE 8bit]

3: Opcode Only
[OPCODE 4bit]

命令セット

OPCODE を 4bit としたため、命令の種類は 16 種類です。現在のところ、以下の命令セットでどうかな、とおもっていますが、恐らく変更すると思います。

転送

1. LDI (2)
イミディエイトデータをアキュムレータに転送

2. IN (3)
IN ポートからアキュムレータに転送

3. LD (1)
アキュムレータから RAM に転送

4. LDR (1)
RAM からアキュムレータに転送

5. OUT (3)
アキュムレータから OUT ポートに転送


ジャンプ

6. JMP (1)
無条件ジャンプ

7. JC (1)
キャリーフラグ有効でジャンプ

8. JNC (1)
キャリーフラグ無効でジャンプ

9. JZ (1)
ゼロフラグ有効でジャンプ

10. JNZ (1)
ゼロフラグ無効でジャンプ


演算

11. ADD (1)
アキュムレータ = アキュムレータ + RAM

12. SUB (1)
アキュムレータ = アキュムレータ - RAM

13. SHIFTR (3)
アキュムレータを右シフト

14. SHIFTL (3)
アキュムレータを左シフト


デバッグ
15. CLK_AUTO (3)
システムクロックを有効にする

16. CLK_MANUAL (3)
システムクロックを無効にする(マニュアルクロックを使用する)

アキュムレータ <--> RAM 間のデータ転送命令のネーミングが決心がついていません。CLK_AUTO と CLK_MANUAL はステップ実行のデバッグ用です。CKL_MANUAL でブレークポイントをはってマニュアルクロックでデバッグしたあと、CLK_AUTO でシステムクロックを有効にして処理を継続します。ステップ実行、絶対必要。

お正月休みの進捗はこんなところ。。