31-Jan-2015
［こんなん作ってみました(2)］

20-Jan-2015の続き。とりあえずFIFO経由での描画にも対応させてみました。ソースコードと、ベンチマーク結果(ods)を転がしてみます。やっていることは大したことではないのですが、VMware SVGA IIのレジスタにちょっとヘンな値を書き込むだけでVMware自体がクラッシュして落ちてしまうなんてこともあり、思っている以上に時間を使ってしまいました。

B-benchを使用したベンチマークで得られた結果より、こんな傾向がありそうです。

なんとなくですが、画面表示のエミュレーションが忙しくなるとディスク周りのエミュレーションに手が回らなくなり、画面表示のエミュレーションをサボらせるとディスク周りのエミュレーションに余裕が出るとか、そんな気がします。PC全体を一つのCPUで真似る（ということにしておく）以上、当然といえば当然なのですが。

これもなんとなくですが、FrameBufferを使用した場合は適当な周期で画面全体を描画するのに対し、FIFOを使用した場合は適当な周期で画面描画を行う点は変わらないものの、更新が必要な範囲のみを描画するために若干速くなるのでしょう。また、更新が必要な範囲をある程度溜め込んでおいた場合、適当に整理してまとめて描画するといった処理を行い、画面描画の頻度を減らす工夫をしている可能性も考えられます。

♪

使用環境を簡単に書いておくと、AMD A8-3850を使用したPC、Windows 8.1 Pro(64bit)上で動作するVMware Player 7.0.0、T-Kernel 2/x86の.vmxファイルその他仮想マシンの構成はT-Kernel 2/x86のCD-ROMにあるものをそのまま使用しています。

♪

今回のソースコードは、画面への描画要求があった場合はこれをFIFOへ複数溜め込むことはせずにその都度画面描画を行わせるよう、ベンチマークスコアを犠牲にする設定をデフォルトにしています。というのも、マウスポインタの動きがどうにもガクガクで見ていられないというのがその理由だったりします。

正直言ってこの辺の味付け、どうするのが正解なんですかね。今回は実験ということもあり意図的に極端な事をやっていたりするのですが（FIFOの使い方も、一部VMware SVGA Device Developer Kitに書かれた記述に反している部分があります）。とりあえずソースコードも出しているし、不具合や不満があってもまあなんとかなるっしょということで投げてしまいます。59.40kg(06:05)

03-Jan-2015補足：超漢字Vへも移植してみました。ベンチマーク結果も大体似たようなものではあるのですが、FIFO経由（使用するFIFOの量は最小）での描画性能が超漢字標準のドライバよりも若干落ちるのが気になります。HDDのDMAはoffとしているからなのか、それとも他の理由かまでは調べていません。

25-Jan-2015
［渕野辺線12, 13号で工事してる］

先週、町田街道の某交差点で信号待ちをしている時にふと横に目をやると妙な鉄塔があるなー…ということで、昨日見に行ったのがコレ。

tp1243355.jpg tp1243356.jpg tp1243357.jpg tp1243358.jpg

現場にいた方にお話を伺ったところ、仮の鉄塔だそうです。場所はこの辺り。

13号が存在していたと思われる場所は、更地になっています。大体この辺で撮っています。

tp1243359.jpg tp1243360.jpg

12号鉄塔の脇には、既に新しい鉄塔が建てられています。標識類はまだ取り付けられていないように見えます。

tp1243362.jpg tp1243363.jpg tp1243365.jpg

工事自体は昨年の夏頃から今年の夏頃にかけて行われるようです。

tp1243364.jpg

渕野辺線の他の区間でも、何か工事が行われているのでしょうか？気になるところです。58.35kg(05:35)

25-Jan-2015
［OpenBSDではよくある話。(3)］

28-Oct-2009に書いたOpenBSD/amd64上でbinutils-2.18 + gcc-3.4.6 + newlib-1.17.0で無理矢理作った超漢字開発環境の話と、05-Oct-2014に書いたOpenBSD/amd64上でbinutils-2.19.1 + gcc-4.2.4 + newlib-1.19.0に置き換えた話の続き。

実は今まで気づかなかったのですが、デバイスドライバの一部では$(BD)/lib/i386e2/reloc.lnkを修正しないとこんな風にエラー(ER_REC)を発生してロードできないバイナリを作ってしまいます。


[/SYS]% kerext cpumsr-before.elf
cpumsr-before.elf: Can't Loaded System Program -2162688
[/SYS]% kerext cpumsr-after.elf
KEREXT cpumsr-after.elf [16] c06d3000 - c06d6000
[/SYS]%

この現象はgcc-3.4.6, gcc-4.2.4のどちらでも発生します。修正前のreloc.lnkを使用して生成したELF形式のオブジェクトをreadelfで読み出すと.rodata.str1.1および.rodata.str1.4セクションがそれぞれ単独で存在してしまうのがER_RECの原因のようです。

参考として、reloc.lnk修正前後のバイナリ一式を転がしておきます。ひょっとすると、$(BD)/lib/i386e2/{demand.lnk,shared.lnk}についても修正が必要になるかもしれません。58.55kg(03:15)

20-Jan-2015
［こんなん作ってみました］

加工して作ったネタ画像にしか見えないのですが。

20150120.png

T-Engine Forumが配布しているT-Kernel 2.01.03のEM1-D512向けスクリーンドライバを改造して、VMware SVGA Device Developer Kitを突っ込んでみたものを、T-Kernel 2/x86開発キットに食わせたという…ただそれだけなんですけどね。

ソースコードはそのうちどこかに上げておきますが、任意の解像度で使えるというくらいの利点しかないですね…B-benchでFrameBuffer/FIFO経由のそれぞれの描画速度を測っても、大きな速度差はありませんし（FIFO経由の方が数%程度速いですが、体感では変わりません）。

おそらくデバイスドライバのインタフェース周りを修正すれば超漢字Vでも載りそうな気がしますが、労力と得られるものが見合うかどうかは謎です。

♪

μT-Kernel 2.0のリファレンスコードが出ていたり、μT-Kernelも1.01.03とバージョンアップしていたりして、手元にあるコードをどうしたものかという方がむしろ頭痛の種だったりします。

なにしろバージョンアップを行う度に全てのコードのコメントに埋め込まれているバージョン番号を変えてくれるので（コードを変更していなくてもコメントだけは書き換えている）、「実際に」変更のあった箇所をdiffで探すだけでも一苦労なんです。59.00kg(06:10)

21-Jan-2015補足：とりあえずソースコード上げときます。配布用のuCodeは00070047です。

22-Jan-2015補足：ソースコードを整理し、VMware SVGA Device Developer Kitは使わずに同等の内容を実現してみました。なお、FrameBuffer経由での描画のみの対応となります。

14-Jan-2015
［T-Kernel 2/x86評価キット・開発環境覚え書き］

超漢字に関してとある相談をしたところ、パーソナルメディア株式会社様の御厚意により、T-Kernel 2/x86評価キットをお借りすることになりました（この場を借りてお礼申し上げます）。開発環境はLinux-i686向けの物となっていますが、ここではOpenBSD-5.6/amd64で開発環境を再構築してみることにします。

とりあえずツール類のビルドと再インストールができたというだけの話であるため、ツール類がきちんと動くことを保証するものではありません。

なお、「とある相談」の内容について書いておくと、05-Oct-2014の超漢字開発環境（非公式）のC++対応を検討する際に、C++ライブラリソースの内容ではちょっとよく分からないので超漢字よりは新しいgccを使っているであろうT-Kernel 2/x86評価キットの修正内容を見せてもらうことはできませんかというものです。

超漢字開発環境ではgccをほぼ無修正に近い形で使用していたのに対し、T-Kernel 2/x86評価キットの場合はそれ用の改造があちこちで行われています。ちょっと見ただけでさっくり反映できるとは思えず…余計に悩みそうな感じです。

頭の痛い問題は棚の上にあげて、適当な時期に86duino上で動くかどうかのチェックもしてみたいところですと書いて、ここは逃げておきます（おい）。58.65kg(06:20)

12-Jan-2015
［SSD導入（クロスコンパイラに関する覚え書き）］

色々思うことがあり、思い切って導入してみました。CrucialのMX100、512GBのモデルです。その際にOpenBSD-5.6/amd64をインストールして環境の再構築を行ったのですが、クロスコンパイラの再インストールにかなり手こずったのでそのメモを。

♪

・注意事項

・h8300-hms

binutils-2.16.1
../configure --target=h8300-hms --prefix=/usr/local --disable-nls
gcc-4.2.4 + newlib-1.19.0
../configure --target=h8300-hms --with-newlib --prefix=/usr/local --disable-nls --enable-languages=c

・h8300-elf

binutils-2.19.1
../configure --target=h8300-elf --prefix=/usr/local --disable-nls --disable-werror
gcc-4.2.4 + newlib-1.19.0
../configure --target=h8300-elf --with-newlib --prefix=/usr/local --disable-nls --enable-languages=c

・sh-coff

binutils-2.16.1は、gprof/flat_bl.mがエラーを起こすので、configureを修正してgprofのビルドを回避する。

binutils-2.16.1
../configure --target=sh-coff --prefix=/usr/local --disable-nls
gcc-4.2.4 + newlib-1.19.0
../configure --target=sh-coff --with-newlib --prefix=/usr/local --disable-nls --disable-libssp --enable-languages=c

・sh-elf

binutils-2.19.1
../configure --target=sh-elf --prefix=/usr/local --disable-nls --disable-werror
gcc-4.2.4 + newlib-1.19.0
../configure --target=sh-elf --with-newlib --prefix=/usr/local --disable-nls --disable-libssp --enable-languages=c

・arm-elf

gcc-4.2.4はThumbに対応させるため、gcc/config/arm/t-arm-elfを修正する。

binutils-2.19.1
../configure --target=arm-elf --prefix=/usr/local --enable-interwork --enable-multilib --disable-nls --disable-werror
gcc-4.2.4 + newlib-1.19.0
../configure --target=arm-elf --with-newlib --prefix=/usr/local --enable-interwork --enable-multilib --disable-nls --enable-languages=c

・arm-none-eabi

gcc-4.8.3はCortex-M0に対応させるため、gcc/config/arm/t-arm-elfを修正する。gcc-4.8.4だとさらに修正が必要そうだったので、ここではgcc-4.8.3を選択した。

binutils-2.24
../configure --target=arm-none-eabi --prefix=/usr/local --enable-interwork --enable-multilib --disable-nls --disable-werror
gcc-4.8.3 + newlib-2.2.0
../configure --target=arm-none-eabi --enable-languages=c --prefix=/usr/local --enable-interwork --enable-multilib --with-newlib --disable-nls --disable-libssp --disable-libgomp --with-gmp=/usr/local --disable-lto

・x86_64-elf

binutils-2.24
../configure --target=x86_64-elf --prefix=/usr/local --disable-nls --disable-werror
gcc-4.8.4 + newlib-2.2.0
../configure --target=x86_64-elf --enable-languages=c --prefix=/usr/local --with-newlib --disable-nls --disable-libssp --disable-libgomp --with-gmp=/usr/local --disable-lto --with-abi=m64

・x86_64-x32-elf

binutils-2.24
../configure --target=x86_64-x32-elf --prefix=/usr/local --disable-nls --disable-werror
gcc-4.8.4 + newlib-2.2.0
../configure --target=x86_64-x32-elf --enable-languages=c --prefix=/usr/local --with-newlib --disable-nls --disable-libssp --disable-libgomp --with-gmp=/usr/local --disable-lto --with-abi=mx32

♪

x86_64向けのgccを4.8.3から4.8.4に変えましたが、これはLinus Torvalds、 GCC 4.9.0のコード生成にブチ切れるにある、-mno-red-zoneを指定した際の最適化に絡むバグを回避することが目的です。とはいえ、gcc-4.8.4で直っているかどうかはよく分からないのですが…（gcc-4.9.3を選んだ方が良かったか？）。

multilibを有効にしたgccでの、ライブラリのビルド中にSegmentation Faultが発生してビルドが停止する問題には本当に悩まされました。HDDをA8-3820機からA8-3850機に繋ぎかえても問題が再現する一方で、Pentium Dual-Core機では再現しなかったことから、AMD/Intelの違いによる問題か？とすら思ってしまいましたし。マシントラブルではないことが分かったので（特に財布へのダメージがこれ以上大きくならないという点で）安心しましたが…この問題につまづかなければ無駄な時間を使うことはなく、環境の移行はより早く終わっていたことは間違いありません。

SSDの速度については、HDDよりは確実に速いと感じられるものの、劇的な高速化を期待するならCPUも併せてアップグレードする必要がありそうです。今回の問題ではgccを何度も何度も何度も何度もと書く程度では済まない回数をビルドしていますが、こういうことをしていると高速なマシンで時間を買わないとやってらんねーという気分に段々なってきます。

とりあえず、Phenom9500機の頃から使っていたHDDなので老朽化が気になっていたことと、マシンの周辺で子供が遊び回ってHDDがクラッシュする（データ消失の）危険が遠ざかっただけでも良しとします。実際、子供が突っ込んできてマシンがハングアップするという目にあっていますので…58.50kg(06:30)

05-Jan-2015
［面倒な…］

Setting Up Long Modeを参考にこんなコードをでっち上げて、動くかどうかを試してみたいのだけど、いざ動かすとなるとブートローダーが必要になる訳で。A20線の設定とか色々面倒なことはしたくないし。

qemuの-kernelオプションはvmlinuz形式のLinuxカーネルを起動するためのものであり、その辺のコードを適当に動かすために用意されている訳ではなさそうです。となると、GRUBから起動できる自作OSを作成するを参考にしてGRUBから起動できるバイナリを作る必要がある訳ですが…

OpenBSDのportsにはGRUB legacyはあるもののi386専用で、現行のGRUB2は無かったりします。ざっとコードを見る限りお手軽に__OpenBSD__足せばどーにかなるだろという代物ではなく、がっつり移植する必要がありそうです。

大人しくLinux使っとけってことになるんですかね？それもまたそれで面倒なんですけど…58.45kg(04:05)

02-Jan-2015
［あけましておめでとうございます。］

本年もよろしくお願いします。

♪

こういう時くらいしか実験にじっくり時間を使うことができないので、前から気になっていたx32 ABIを見てみることにしました（あんまり流行っていないみたいですが）。

gccのソースコードを見る限りでは、x32 ABI向けgccのconfigureにある--with-multilib-list=m32,m64,mx32はx86_64-*-linux*でないと使えないので（細かいことを書くとキリがないのでそういうことにしておく）、freestanding環境でx86_64-elf等とする場合はconfigure時に--with-abiで指定しないとダメなようです。

とりあえず、arm-none-eabi用に使っていたbinutils/gccのソースを使い回してこんな感じに。

binutils-2.24(mx32)
../configure --target=x86_64-x32-elf --prefix=/usr/local --disable-nls --disable-werror
gcc-4.8.3(mx32)
../configure --target=x86_64-x32-elf --enable-languages=c --prefix=/usr/local --with-newlib --disable-nls --disable-libssp --disable-libgomp --with-gmp=/usr/local --disable-lto --with-abi=mx32
binutils-2.24(m64)
../configure --target=x86_64-elf --prefix=/usr/local --disable-nls --disable-werror
gcc-4.8.3(m64)
../configure --target=x86_64-elf --enable-languages=c --prefix=/usr/local --with-newlib --disable-nls --disable-libssp --disable-libgomp --with-gmp=/usr/local --disable-lto --with-abi=m64

gcc -O0 -Sでアセンブラのソースを吐かせるとこうなります。

mx32m64

	.file	"test.c"
	.section	.rodata
.LC0:
	.string	"Hello, world!"
	.text
	.globl	main
	.type	main, @function
main:
.LFB0:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movl	%esp, %ebp
	.cfi_def_cfa_register 6
	subl	$32, %esp
	movl	%edi, -20(%ebp)
	movq	%rsi, %rax
	movl	%eax, -24(%ebp)
	movl	$-2147483648, -4(%ebp)
	movl	-4(%ebp), %eax
	movb	$0, (%eax)
	movl	$.LC0, %eax
	movl	%eax, %eax
	movq	%rax, %rdi
	call	puts
	movl	$0, %eax
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE0:
	.size	main, .-main
	.ident	"GCC: (GNU) 4.8.3"



	.file	"test.c"
	.section	.rodata
.LC0:
	.string	"Hello, world!"
	.text
	.globl	main
	.type	main, @function
main:
.LFB0:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	subq	$32, %rsp
	movl	%edi, -20(%rbp)
	movq	%rsi, -32(%rbp)
	movq	$-2147483648, -8(%rbp)
	movq	-8(%rbp), %rax
	movb	$0, (%rax)
	movl	$.LC0, %edi
	call	puts
	movl	$0, %eax
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE0:
	.size	main, .-main
	.ident	"GCC: (GNU) 4.8.3"

元となるソースコードはコレ。


#include <stdio.h>

int main(int argc, char *argv[])
{
	volatile unsigned char *ptr;

	ptr = (volatile unsigned char *)0xffffffff80000000LL;
	*ptr = 0;

	printf("Hello, world!\n");
	return 0;
}

今のところこれで何かをするつもりはないのですが、x32で遊べる機会があるといいなあとは思っています。58.85kg(06:55)