バイナリかるたをリニューアルしました.

 

https://kozos.jp/binary-karuta/

↑ここの「バイナリかるたのサンプル」「バイナリかるたのサンプル(初心者向け)」「バイナリかるた生成ツール」です.

 

「初心者向け」は,入門向けにカードを限定してファイル種別等も入門向けにして,1枚シートで印刷できるようにしたものです.

 

バイナリかるたは独自の生成システムがあって,makeするだけでかるた札のデータやスライドPDFを自動生成してくれるというものなのですが,今回大幅にリニューアルしました.新規データも追加されています.

もともと2013年ごろにSECCONで始めたバイナリかるたですが,その後に書籍「バイナリで遊ぼう」の題材になったり,とある会社のノベルティグッズになったりしましたが,最近とあるところでやる機会があったので,良い機会なので生成システムをリニューアルしました.

今回は,市販の標準的な名刺シート用の印刷データ生成を追加しています.

標準的な名刺シートというのはA4サイズで2×5で10枚の名刺が作成できるものですが,これに印刷するためにサイズ合わせして縁塗り足しも追加した印刷用データを生成してくれます.

(生成後のデータも添付しています)

 

これを名刺シートに印刷すれば,自前でかるた札の印刷が可能です.

(ただコンビニとかの印刷サービスとかでは,印刷用紙の持ち込みはほとんど対応していないので注意してください(紙づまり等するとトラブルになる可能性有り).自宅のプリンタか,持ち込みの名刺用紙での印刷を受け付けてくれる印刷所とかでの印刷が必要)

makeしなおせば自前でデータ作成も可能ですが,必要ツールをインストールする必要があるのと,あと私はFreeBSD上でやっているので,DebianやUbuntuとかだと動作や生成データに微妙な違いがあるかもしれないです.

ホームページ上では、他のシートサイズに合わせた印刷用データも配布しています.

A-ONEの通常名刺シート,角丸マルチシート(キャッシュカードサイズ),つり下げ名札シート,店頭POP用シートのサイズに合わせたデータがあります.

新規データは,初心者向けにテキスト系のデータを追加しました.

また今まで無かった音声系,ファイルシステム系を追加しました.


Let's binary karuta!
 

久々に,本を出しました.(大熱血アセンブラ以来か…)

 

独自言語「NLL」の入門書です.
電子と紙の書籍があります.紙の書籍はオンデマンドなので,ネット上での注文販売です.
https://www.amazon.co.jp/dp/4295603392/


独自言語を使うことのメリットを出したかったため,言語の入門書というだけでなく,プログラミングによって算数の問題をいかに解くか?というテーマで書いてみました.
また,言語仕様を淡々と説明するのでなく,実験しながら修得するというやりかたにしたかったため、キャラクターの対話形式で書いてみました.(私としては、初)

入門書なので技術レベル高い本というわけではないですが,自分の自作の独自言語で本が出せたので,私としてはまた今までとは違った嬉しさがあったりします.

プログラミングが必修化されて久しいですが,プログラミングの入門というと,多くはゲーム作りを題材にしています.
これはこれで良いとは思うのですが,プログラミングに対して「ゲームを作るためのもの」というイメージが強くなるため,他のことに使うという発想,例えば身の回りのなにかに役立てるということに繋がりにくい(=修得のためのモチベーションを得られにくい)という部分があるのでは?と思います.

 

プログラミングがもっと身の回りの問題解決に役立てられるということを知ることができれば,じゃあできるようになってみたいというモチベーションをもっと得られやすくなるんじゃあないかなと.

 

そこで算数なのですが,算数の問題を解くっていうのは,子供にとってはかなり身近なテーマだと思うわけです.

これがプログラミングによってできるのであれば,それはプログラミングをやることのモチベーションに繋がりやすいのではないかと.

そのように考えてみると,算数の問題を解くことにプログラミングを使うっていうのは,かなり魅力的なんですよね.
理由は,プログラムを書くことで,コンピュータの計算力に任せて力任せに解くような,要するに教科書的ではないけど「理論が単純で理解は簡単な」解き方ができるからです.(例えば総当りで解くとかそういうのです)

最大公約数とかだって,公約数を出したり素因数分解したりしなくても,1から順にループして割った数がゼロになるやつ,っていう総当り的なやりかたで簡単に解くことができます.

もちろん前者のやりかたよりも計算量はかかるわけですが,プログラム書いてコンピュータが頑張ればいいだけですし,今どきのPCなら1万くらいの数までやったとしても一瞬でしょう.

 

別に教科書的なやりかたを否定するわけではないですしそれはそれで必要だとは思うのです.

が,それとは発想が違った「計算力に任せて解く」っていうやりかた「も」知ることで,解きかたに選択肢を持てるようになるわけだし,別の視点からの解きかたを知ることが理解の助けになるかもしれないし,そもそもそれで問題解決できるという発想も持てるようになるわけだし,それはそれでいいんじゃないかと思うわけです.

 

まあこのへんの詳しい話は書籍中に書きましたのでそちらで.

 

独自言語を作っています.(「NLL」という言語です)

 

https://kozos.jp/nll/

昔のBASICに似た感じの文法で,行単位・コマンドベースで記述する感じです.

 

「とりあえず,やりたいことをやりたい」というプログラミングの入門者が,何かパッとプログラムを書くとして,知らなければならない文法事項や概念が多いと,本来考えなければならない処理の組み立てとかそういうこと以前のところで詰まってしまいます.

 

そこで,プログラムを書くために覚えなければならない文法事項や概念を最低限にすることで,いくつかの文法事項さえ覚えればあとは上から順に丁寧に読めば理解できる(はず),しかし演算機能は(入門者向けの言語だからといって簡略化することはせずに)普通の言語並みにあるので,書こうと思えば本格的なプログラムも書ける(はず)という方針で作ってみました.

つまり演算機能は普通並み,しかし文法事項は最低限,という言語です.

 

例えば変数にはグローバルとローカルの違いは無く,すべてグローバルです.

また関数(サブルーチン)には範囲という概念は無く,サブルーチン呼び出しがあればそこにジャンプして,RETURNがあればジャンプ元に戻るというだけです.これによって関数の範囲という概念を無くしています.

 

もちろん工夫すれば,ローカル変数のような書き方をすることはできます.

でも最初のうちはそういうことはせずに,変数はすべてグローバルとして考えればそれでプログラムは書ける,というようになっています.

 

グラフィック機能やサウンド機能もありますので,ゲームを作ったりすることもできます.

 

SecHack365の2022年度の募集が開始されています.簡単に言うと,年間かけたハッカソンイベントです.

詳しくは以下を参照してください.

https://sechack365.nict.go.jp/

SecHack365ですが,どのコースやゼミに応募するかで悩んでいる人がいると思いますが,それについて,以下は私個人としての考えです.

SecHack365は今年は5コースからなり,またコース内がゼミで分かれているとこもあります.

で,やることややれることは,コースやゼミによって全然違ったりします.
コースやゼミによって方針ややりかたも全然違ったりします.

また,長期間に渡るイベントです.

なのでその方針ややりかたといったところでミスマッチ出るときついので,コースを十分に吟味して選んだほうがいいと思います.

つまりコースを選ぶとき,「この技術を扱っているから…」みたいにして技術分野だけでコースを選ぶのでなく,コース概要やゼミ説明を良く読んで,コースやゼミのやりかた・方針を調べて,それが自分に合うかどうかでコースを選ぶことをおすすめします,ということです.

なにせ長期間やるものですので,分野が合うか以上に,そのコースの方針が自分に合うかどうかが超重要です.

分野の違いは自身で努力・学習して自律的に開発することで埋められます.

でも方針が合わないのは埋めにくく,さらに長期間だと,自分に合わないやりかたでずっと続けるのはきついことになるからです.

なのでどのコースでどのような技術分野を扱うかだけでなく,そのコースの方針ややりかたをよく調べておくことをすすめます.

SecHack365のコースは「XX駆動コース」という名前になっています.「駆動」という言葉がついています.

この「駆動」という言葉の意味は「XXすることから物作りを始める」という,物作りに対するアプローチの違いです.
分野でなくそうしたアプローチの違いでコースを分けています.

あまり考えずにパッとライトにものづくりを始めてしまいたいとか,作る意義とか目的とか世の中の需要とかを充分に検討してからものづくりを始めたいとか,そういうアプローチの違いです.

こういうのは,どれが優れたやりかたかというものではなく,どのやりかたが自分に合うかの問題です.

長期間イベントなので,分野よりもアプローチが自分に合うかどうかのほうが重要です.しっかりコースを選ぼう.

 

で,私が担当させていただくのは学習駆動コースというところなのですが,まず以下に詳しく説明していますのでそちらを参考にしてください.
https://kozos.jp/sechack365/

学習駆動コースは,作りたいものをひたすら作っていただくコースです.
坂井ゼミ・今岡ゼミ・コンテンツゼミ・コンテストゼミ・砂場遊び開発ゼミの,5つのゼミがあります.
ゼミごとに方針ややれることが「全然」違うので,応募を考えているかたは必ずゼミ説明をよく読んで熟考してから応募してください.

坂井ゼミでは組込みやOSなどのソフトウェアの低レイヤー周りを扱います.
今岡ゼミではFPGAや通信といったフィジカル系を扱います.

コンテンツゼミでは,セキュリティを啓発するための何らかのコンテンツの作成と普及を目指します.
小説・絵本・マンガ・映像・競技などの「非技術系」のコンテンツでもOKです.

で,それらを自身で考案し,作り,作るだけでなく公開して世に普及させることを目指します.

作詞・作曲やダンスなども可能性があるかと思います.

コンテストゼミは,今年新設されました.

ここではなんらかの競技やコンテストを考案し,作り,実施し,普及させることを目指します.

自分で考えた競技を,自分で作って実施してみる,というのが趣旨です.


砂場遊び開発ゼミではオンライン開発を主体として「自発性」「非同期性」を重要視してグループ開発します.
具体的には役割分担や打合せや方針決めや互いの調整をしない・リーダーは決めない・途中での分離も自由として,緩い疎結合で非同期で各自が好きにものづくりします.

今年の開発テーマはこのブログでも紹介している「NLCC」です.(私が自作している独自のCコンパイラです)


学習駆動コースでは,基本的に作りたいものをどんどん作ってもらいます.さらに付加的な学習を,やりたいようにやっていただくことを推奨しています.(ただ推奨程度で,強制するようなことは無いです)
ものづくりが好きで,考えるよりもまず手が動く,自分で作ってみたい,ついでに興味の向くまま寄り道もしたい,いろんなことができるところがいい,という人に向いています.寄り道的な開発や学習を許すので,例年,いろんな寄り道をする人がいます.(むしろ寄り道することは推奨です)
 

学習駆動コースに向いてるのは「有用性とか考えてないが作りたいから作る」「とりあえず作ってみるというやりかたが好き」という人です.
凡庸なアイディアでも車輪の再発明でも非実用的でも作り捨てでもOKです.

作ってみたいと思ったらまずは作ってみて「作って作りまくる」「作って失敗したら,また別のを作ればいい」というコースです.

 

で,以下は私が担当する坂井ゼミについてです.

 

坂井ゼミではおすすめの開発テーマを提示しており,主に低レイヤー分野のテーマになるのですが,それ以外にも,持ち込みテーマを受け入れます.
ただし技術的なことは教えられない可能性が高いので,自身で自律的に開発を進められることが前提になります.
過去には動画編集ソフト開発といった持ち込みテーマがありました.

 

あと坂井ゼミの方針ですが,私は基本的にモチベーション至上主義です.
なので本人がやりたい・作りたいと思うことをまずやってもらい,それを止めたりすることは基本的にありません.
「これやりたいです」に対しては「あーいいんじゃない,やりたいならばやってごらん」です.

あと坂井ゼミでは,私自身も開発テーマを持って,年間かけてものづくりをします.

トレーニーと一緒に私もものづくりするという感じで進めます.
私がどんなふうにものづくりをしていくのか,リアルタイムで見ることができます.ぜひいっしょにものづくりをしましょう!
 

ブログが長らく休止状態になっていたのですが,現在,nlccという完全独自のCコンパイラを開発しています.
https://kozos.jp/nlcc/

nlの意味のひとつは「No Learn, No Listen」で,「何も見ず,聞かず,参考にせずに作る」です.まあ特別そうした確固たるポリシーがあるとかではないですが,そういうやりかたで作ってみたら面白い…というか独自性あるものになるかもと思って,そういうやりかたで作っています.

なのでおそらく,実装や用語や考え方が独自になっている部分が多いと思います.

前段階として,nlshという独自シェル(見ためはtcsh互換)と,nllibcという独自の標準Cライブラリを開発していて,それらと合わせた形で「nlux」として配布しています.

 

一応,gcc(に含まれる,cc1相当)の代替となることを目指して開発しています.

 

nlccやnlshは,nllibcを利用することで,システム標準のライブラリを一切使わずにビルドすることができます.ライブラリ的に完全に閉じてビルドできる,ということです.nllibcはスタートアップやシステムコールラッパーも持っているので,システムが持つそれらも不要です.
さらにnlcc/nlsh/nllibcも,nlccでコンパイルできます.
つまり,nllibcを使ってnlccをビルドして,そのnlccを使ってnllibcをビルドして,さらにそのnllibcを使ってnlccをビルドして...ということができます.

もちろん,システム標準のライブラリ(libc)を使ってビルドしたり,gcc/clang等を使ってビルドすることも可能です.

また,ヘッダファイルはシステム標準のものを使うが,ライブラリの本体はnllibcを使う,という方法でビルドすることも可能です.(ただこの対応はシステム依存部がややこしくなるので,将来的に廃止するかもしれない)

システム標準のヘッダファイルをインクルードしたファイルを,コンパイルすることもできます.(つまりFreeBSDやDebianが持つヘッダファイルもコンパイルを通すことができる,ということです)

FreeBSD/Debian/CentOSでのビルドに対応しています.(ただCentOS対応は将来的に廃止するかもしれない)
要するに,組合せ自由でビルドできる,ということです.

nlccの最大の特徴は,「アーキテクチャ対応する際の対応必要部分を最小限にしてある」という点です.
数百行程度のファイルを用意すれば,それで新規アーキテクチャに対応できます.
数百行のファイルを用意するだけで新しいアーキテクチャに対応できるとしたら,すごく面白いんではないかなと.

 

というように,nllibc使ってシステムのライブラリ使わずビルドできる,組合せ自由でビルドできる,アーキテクチャ対応しやすい,などといった特徴がありますが,まあ大熱血アセンブラ入門の著者がCコンパイラ作ったらこんなふうになるだろう,という考えでそうしてみました.

アーキテクチャ対応しやすいというのは,アーキテクチャ全体を俯瞰して処理や設計を極力共通化することと,ビルトインを充実させることで実現されています.
アーキテクチャ対応する際には,処理に応じたアセンブリの命令を登録するのですが,登録が面倒ならば未登録にしておけば,ビルトインで等価の処理をしてくれます.(もしくは等価の別処理(!=は==の演算での別処理に置き換えるとか)にしてくれます)
たとえばかけ算や割算は,命令を登録しなくてもOKです.登録しなければ,ビルトインが使われます.まあソフトウェア計算になるので要するにループ回した計算になるのでたいへん遅くなりますが,それでもとりあえず動くコードを生成してくれますし,対応の初期はとりあえずビルトインにしておいて検証して後できちんとした命令を登録する,ということが可能です.
まあもちろん,ビルトインが存在する処理に限られます.今のところシフト演算・かけ算・割算・剰余算・ビット反転(~n)・符号反転(-n)はビルトインに置き換え可能,符号拡張・比較演算の一部(==と<以外)は等価の別処理に置き換え可能です.つまりこれらは対応しなくても,とりあえずアーキテクチャ対応することはできます.

 

可変長引数,ビットフィールド,構造体の引数渡しにも対応しています.

(構造体の戻り値にも対応しているが,開放済みスタックを利用しているので不十分だがまあとりあえずは動くと思う)

 

現状,以下のアーキテクチャに対応しています.
x86/x86_64 (実際に動作し,テストセットがすべて通りnlcc自身をセルフビルドできるレベル)
AArch64/ARM/MIPS/PowerPC/Thumb/MIPS16 (とりあえずアーキテクチャ対応のファイルを用意し,アセンブリは出力できるが未検証,というレベル)
OSECPU (実験的実装のレベル)

 

nllibcも様々なアーキテクチャに対応しているので,原理的にはARMやMIPS上でもnllibc使ったセルフビルドができるはず...
(ただしnlccはコンパイラのみなので,プリプロセッサ・アセンブラ・リンカは別途必要)

64ビット対応はしてありますが,ホストが32ビットの場合には,long long のような64ビット値は64ビット値でなく,32ビット値として扱われます.(sizeofでは64ビット値として扱われるが,演算などは32ビットで行われる.なのでひとまず動作はするという感じ)

多種アーキテクチャを意識しているというのはあるのですが,そのぶん,最適化というものをほとんど一切していなくて,生成されるアセンブリの効率は悪いです.
gccでビルドしたnlccと,nlccでビルドしたnlccで,コンパイル速度を比較すると,明らかに遅いです.
原因はいろいろわかってはいるのですが,多種アーキテクチャに対応しやすいことを優先させていて,とりあえず速度向上の改良は後回しとしています.