GR-SAKURA
GR-KURUMI
GR-COTTON
GR-CITRUS
GR-PEACH
GR-KAEDE
GR-ADZUKI
GR-LYCHEE
GR-ROSE
GR-MANGO(*)
SNShield
Web Compiler
IDE for GR
TOPPERS関連
女子美コラボ
その他
※プロデューサミーティング中
作り方使い方資料
イベント関連
作品記事
体験記事
ライブラリ
ツール
その他・過去ファイル
生地に練りこんで焼き上げたクルミパン、すり鉢ですって野菜と和えたクルミ和え、冷たいお蕎麦にクルミだれ、クルミ饅頭、クルミ豆腐、クルミ餅。クルミは私たちの毎日の食卓に欠かすことができません。そんな私たちの生活と切っても切り離せないクルミについて研究をしてみることにしました。
どうやらこの画像はクルミの萎びた外果皮を剥かずにノギスで計っているところらしい。この動画『20141023 《财富故事》 文玩大集 火遍京城』を見ると記事中での「写真は北京近郊の市場でクルミの大きさを計る業者」という状況も良くわかる。
「よく使い込まれて年季が入ったようクルミ加工するマシーン」とか平気でありそうですがやはり高級品は人の手で使い込まれたものなのでしょうか。30万円(15800元)とはちょっとした貴金属品並みですね。
関連ニュース 『「幻のキン消し」がヤフオクで30万円超え!屁のツッパリはいらんですよ!』
動画を見ればだいたい内容を想像することができますけれども、 クルミファンを増やすためにナレーションを日本語化してみました!
露店では青い実のまま販売しているみたいで、買ってから中のクルミを取り出すので 1対(2個)のクルミの大きさが同じになるかどうかでドキドキするようですね。北京に行った際はぜひ露店市に寄って極上のクルミを格安にゲットしてきましょう。
日本語訳
中国語原文
2万で買って、使い込んだら30万円になるんでしょうかねー。キン消しも興味のない人から見るとまったく無駄ですよねー^^;
青い実のまま販売して2個セットの中身の大きさにドキドキするってトレーディングカード売るみたいな商売ですね。
カード同様に交換市場とかもありそうな気がします。
大きさが一番大切らしいので、52ミリのクルミを2個で、53ミリ1個分の価値があるとかみたいな雰囲気かもですねー。
動画で「中毒」ってキーワードが出てきましたけれども、結構みんな真剣にハマっていて、 どうやったら「青い実」を見て中の種の大きさを推測できるか研究しているみたいです。 好きな人は一日中、露店のやりとりを見ているたけで暇つぶしてきてしまうようですね。
動画を見ているうちに、なんだか、クルミって何だろうと逆にわからなくなってしまいました。桃の種もクルミになるのかなとか^^;
よくよく考えたら「桃」って付く植物はいろいろありましたねー。
ちなみに「胡」は春秋時代の中国で北狄に位置する胡国のことで胡国原産のクルミは桃の種に似ていたので「胡桃」と呼ばれるようになったそうです。胡瓜とか胡椒とかも、クルミと同様、胡国からの伝来してきたようですね。
クルミはモモに似ているけれども、モモはクルミではない!
HIMEKURUMI(仮)用のGR-KURUMIライブラリ改変の孤独な作業にも飽きてきたので途中経過として上げておきます。
GR-KURUMIの素のスケッチをビルドして、オリジナルでは kurumi_sketch.bin のサイズが約53kBだったのを、様々なテクニック(後述)を駆使して 約22kBとスリムになっています。オリジナルの約53kBのサイズはフラッシュROMの容量が64kBしかないHIMEKURUMI(仮)には重荷だったのですが、これくらい削れればいろいろできることと思います。
今んところデジタル出力とシリアル入出力と温度計測くらいしか動作確認してません。
先の投稿に書いた「様々なテクニック」について、忘れないうちに解説しておきます。
HIMEKURUMI(仮)のライブラリはGR-KURUMIのライブラリを基にしていますが、GR-KURUMIと比べてHIMEKURUMI(仮)のROM容量が少ないことから、生成されるROMイメージが小さくなるよう工夫をしています。
行っている工夫の内容は複数あり、それらは以下の3つのいずれかに分類できます。
この内の前2つに分類される方法はGR-KURUMIにも応用が可能です。
リンク方法の工夫
現在のGNURL78 Tool chainでは、参照されないオブジェクトをリンク時に削除する機能が十分に働かず、生成されるROMイメージファイルが無駄に肥大化するという問題がありますが、これを避けるため、リンクするオブジェクトファイルを一旦 ar にてアーカイブし、それをリンクするという方法を採っています。
これはGNURL78 Tool chainの不具合を避けるための方法であり、将来的にGNURL78 Tool chainが修正されれば必要のなくなるものですが、現状ではGR-KURUMIでも有効な方法と思われます。
ライブラリからの浮動小数点演算の削除
周囲の温度を取得する getTemperature()という関数がGR-KURUMIライブラリのなかで唯一浮動小数点演算を行っており、GR-KURUMIのデフォルトスケッチがこの関数を使用しているため、浮動小数点演算ルーチンがリンクされ、生成される kurumi_sketch.bin が大きいものとなっています。
これへの対策として、getTemperature() の内部の計算を整数演算に書き換え、デフォルトスケッチをビルドした際に浮動小数点演算ルーチンがリンクされないよう変更しています。
勿論、getTemperature() 以外でもユーザーがスケッチのなかで浮動小数点演算を使用すればリンクされる浮動小数点演算ルーチンのサイズに従い生成される ROM イメージファイルのサイズも大きくなりますが、標準のライブラリで暗黙的に浮動小数点演算が使用されるのとユーザーが自ら書いたスケッチのなかで浮動小数点演算を使用されるのとでは意味が異なります。
この方法はGR-KURUMIにも有効です。
.lowtextの利用
GR-KURUMI では mirror 領域(03000H~)に読み出し専用のデータ .rodata セクションを配置する関係で生成される ROMイメージの ~02FFFH までに大きな未使用領域が存在しますが、HIMEKURUMI(仮)ではこの領域を積極的に使用することにより生成される ROM イメージの密度を高めています。
具体的には、ライブラリやスケッチのコードが配置される .text.* セクションを .lowtext.* セクションと改名し、HIMEKURUMI(仮)の mirror 領域の開始アドレス(02000H)以前に配置することで .lowtext セクションと .rodata セクションの隙間を解消しています。
この方法は、ROMの容量が 256kB あり、.text セクションのサイズが 64kB を超えることが可能性として予想される GR-KURUMI では難しいでしょう。
.pltの削除
GNUTL78 Tool chain では 64kB を超えたアドレスに配置された関数を 16bit サイズの関数ポインタで呼び出すための仕組みとして PLT(Procedure Linkage Table)という仕組みを用意しており、前述の .lowtext セクションの直前に .plt セクションを用意し、各関数へのジャンプ命令を配置します。
これは、ROM の容量が 64kB である HIMEKURI(仮) では不要な仕組みであり、.plt セクションは容量の無駄にしかならないので削除しています。
この方法は、関数が 10000H 以降に配置される可能性のある GR-KURUMI では難しいでしょう。
オプティマイザの使用
現在の GNURL78 Tool chain の出力するコードは洗練されているとは言い難く、特にコードサイズについては大きな欠点となっています。
そのための対策として、コンパイラが出力したアセンブリコードをアセンブラが処理する前に簡単な最適化を行うスクリプトを作成し最適化を施しています。このスクリプトは Perl で書かれており、主に分岐命令とアドレッシングの冗長なところを改善する動作をしています。GNURL78 Tool chain にはコンパイル/リンク時に同等の処理を行うコンパイラオプション -mrelax という機能が用意されていますが、現在 GR-KURUMI の web コンパイラで使用されている GNURL78 v14.03 ではこの機能がうまく動作せず、それを補う形となっています。
GNURL78 tool chain の現在の最新版である GNURL78 v15.01 ではこの機能は修正されており、将来的に GNURL78 v15.01 以降を使用するのであれば現在のスクリプトの内容の大半は意味がなく、また GNURL78 Tool chain の出力するコードの冗長な箇所はこれ以外にも判明しているため、この最適化スクリプトの内容は今後も流動的に修正していく予定です。
optlib の試用
GNURL78 Tool chain は C の標準のライブラリとして newlib の libc と libm を採用していますが、これ以外にKPIT による optlib という最適化ライブラリが提供されており、HIMEKURUMI(仮)ではこれを試用しています。
optlib はいわゆるオープンソース製品ではなく、折角オープンソースなプログラムで構成されていた GR-KURUMI のライブラリに非オープンソースな製品を混ぜるのはいかがなものかという葛藤もあるため、今後は元の libc と libm に戻したり、あるいは他のライブラリに移行するかもしれません。
saddrの活用
GR-KURUMI の EEPROM ライブラリは内部でデータ・フラッシュ・ライブラリ Type04を使用していますが、このライブラリの制限として
にスタックやデータバッファは配置できないという制限があります。
このため、この領域は通常の .bss セクションや .data セクションには使用が難しく除外する必要がありますが、もったいないので
という使い方をしています。FFE20H~FFEDFH の領域は他の領域と比べて短い長さの命令でアクセス可能なため、ライブラリのサイズの短縮に僅かながら効果があります。