Raspi2 の浮動小数点演算性能 OpenMP 使用編
先日、Raspi2 の1 コアの浮動小数点演算性能を Linpack で測った 。
OpenMP を使用する Linpack がある。
古いのかも知れないが、 http://people.inf.ethz.ch/arbenz/book/Chapter4/ から、
http://people.inf.ethz.ch/arbenz/book/Chapter4/ompsgefa.tar を得た。
CBLASやBLASのルーチンが必要なので、上記ページからリンクのある、CBLASなどをゲットして、
適当にmake した。
gcc, gfortranは、4.8.2 を使用した。
gcc, gfortran のオプションは下記
CFLAGS = -O4 -fopenmp -march=armv7-a -mfpu=vfpv3-d16
FFLAGS = -O4 -fopenmp -march=armv7-a -mfpu=vfpv3-d16
Raspbian 標準の gcc,gfortran 4.6.3も計測したが、今回は、単精度に関わらず、4.8.2 に負けていた。
(結果の表の、末尾に gcc,gfortran 4.6.3 omp_tread=4 の結果を掲げてある)
Raspi2 は 4 coreである。
OMP thread を1 ～ 4 まで変えて、計測してみた。
システム・クロックは1000MHz
計測結果は、Google表計算で
https://docs.google.com/spreadsheets/d/1HV3aaqAxxXxustCJjhZsqLiypWJ_kZGGwEeE2aybEh0/edit?usp=sharing
結局、
OpenMP で 4 thread だと、1threadの 2.13倍ぐらい。
Raspi2は、1 core Linpack で 166 MFlops 程度だったので…
4thread (4 core) 時は、
166 MFlops × 2.13 = 352.76 MFlops ぐらいの
実効性能であろうか。
Aitendo に行くと、特売品を買ってしまう。
今日は、液晶漏れ(?)だかの、FSTN液晶[COG128X64-18P7565]を100円で買ってしまった。
(今回は、LCDにコネクタ基板がついている シリアルFSTN液晶モジュール（128x64/SPI） [18P7565-2P] 100円を買った)
そもそも、先日に、Aitendoの下記のWebページで、簡単に動きそうなことを読んでいたものだった、だがしかし…
びんぼうでいいの with LCD [U3RLCD18P7565]
シリアルFSTN液晶モジュール（128x64/SPI） [18P7565-2P]
FSTN液晶モジュール(128x64) [COG128X64-18P7565]
下の写真は、苦労の末、動いているもの
しかし、この びんぼうでいいの(Arduino) と接続する情報が、えらい酷いもので…
安定の、Aitendo クオリティ。100円で、長時間、楽しめる(^^;
当該ページに、ある結線のうち、一つは、VSS(GND)ではなく、オープン(N.C)にしておくべきものであった。(下図)
今回、N.Cにしたものは、なにか、意味のある線かも知れないが、調べる気もしなく、得体が知れないので、もう、N.Cでいいや。
コントラストと、しきい値抵抗を、適切に設定すると、結構キレイに映る。
その情報は、下記。
------ ST7565.cpp.patch
-----------examples/st7565lcd/st7565lcd.pde.patch
今日は、液晶漏れ(?)だかの、FSTN液晶[COG128X64-18P7565]を100円で買ってしまった。
(今回は、LCDにコネクタ基板がついている シリアルFSTN液晶モジュール（128x64/SPI） [18P7565-2P] 100円を買った)
そもそも、先日に、Aitendoの下記のWebページで、簡単に動きそうなことを読んでいたものだった、だがしかし…
びんぼうでいいの with LCD [U3RLCD18P7565]
シリアルFSTN液晶モジュール（128x64/SPI） [18P7565-2P]
FSTN液晶モジュール(128x64) [COG128X64-18P7565]
下の写真は、苦労の末、動いているもの
しかし、この びんぼうでいいの(Arduino) と接続する情報が、えらい酷いもので…
安定の、Aitendo クオリティ。100円で、長時間、楽しめる(^^;
当該ページに、ある結線のうち、一つは、VSS(GND)ではなく、オープン(N.C)にしておくべきものであった。(下図)
今回、N.Cにしたものは、なにか、意味のある線かも知れないが、調べる気もしなく、得体が知れないので、もう、N.Cでいいや。
コントラストと、しきい値抵抗を、適切に設定すると、結構キレイに映る。
その情報は、下記。
------ ST7565.cpp.patch
*** ST7565.cpp.org 2015-02-28 17:42:20.000000000 +0900
--- ST7565.cpp 2015-03-01 01:27:20.000000000 +0900
***************
*** 421,427 ****
_delay_ms(10);
// set lcd operating voltage (regulator resistor, ref voltage resistor)
! st7565_command(CMD_SET_RESISTOR_RATIO | 0x6);
// initial display line
// set page address
--- 425,432 ----
_delay_ms(10);
// set lcd operating voltage (regulator resistor, ref voltage resistor)
! // st7565_command(CMD_SET_RESISTOR_RATIO | 0x6);
! st7565_command(CMD_SET_RESISTOR_RATIO | 0x2); /*take@takeoka.net*/
// initial display line
// set page address
***************
-----------examples/st7565lcd/st7565lcd.pde.patch
*** examples/st7565lcd/st7565lcd.pde.org 2013-03-11 20:49:20.000000000 +0
900
--- examples/st7565lcd/st7565lcd.ino 2015-03-01 01:30:00.000000000 +0900
***************
***************
*** 27,37 ****
Serial.print(freeRam());
// turn on backlight
! pinMode(BACKLIGHT_LED, OUTPUT);
! digitalWrite(BACKLIGHT_LED, HIGH);
// initialize and set the contrast to 0x18
! glcd.begin(0x18);
glcd.display(); // show splashscreen
delay(2000);
--- 29,43 ----
Serial.print(freeRam());
// turn on backlight
! // pinMode(BACKLIGHT_LED, OUTPUT);
! // digitalWrite(BACKLIGHT_LED, HIGH);
// initialize and set the contrast to 0x18
! // glcd.begin(0x18);
! glcd.begin(0x10); /*contrast ,
! and check st7565_command(CMD_SET_RESISTOR_RATIO | 0x2);
! take@takeoka.net*/
! glcd.st7565_command(CMD_SET_RESISTOR_RATIO | 0x2);/*take@takeoka.net*/
glcd.display(); // show splashscreen
delay(2000);
Raspberry Pi 2を動かした
Dhrystone など、整数性能は、クロック比程度の性能向上。
Raspi1は、ARM11@700MHz で、Raspi2 は、ARM Cortex-A7@1000MHz。
ARM11は、なかなかいい機械だったので、Cortex-A7と比べてもあまり見劣りしない。
浮動小数点演算 性能が気になる。
組込みCPUなので、期待をしてはいけないが…
Raspi1 の FPU は、ARMの VFP で、ショート・ベクトルとか言っているが、
どないもこないも、遅いしろものであった…
Raspi2 のFPUは、また別物。
Raspbian 標準の gcc (gcc 4.6.3) に
CFLAGS = -O4 -mfp=3 -march=armv7-a -mfpu=vfpv3-d16
で、linpack を make。
システムクロックは、1000MHz と 標準の700MHz で計測。
--- 1000MHz ---
--- 700MHz ---
コア1つで、この性能なら、組込みCPUとしては、まぁ速い。
4コアなので、OpenMP とかで並列に動けば、まぁまぁいいかも知れない。
だが、キャッシュの食い合いとか、内部のバンド幅のせいで、性能が出ないかも知れない。
OpenMP版Linpack も動かしたが、Flops 値が、今は出せていない。
上記で使用したコンパイラ
2015/FEB/27 追記
kkojimaさんのコメントにより…
gcc-4.8 に
CFLAGS = -O4 -march=armv7-a -mfpu=vfpv3-d16
で、linpack を makeし計測。
システムクロックは、1000MHzで計測。
単精度はそこはかとなく遅い気がする(700MHzでは、はっきりと遅い)。
が、倍精度は、速いようだ。
これがコンパイラの力か…
でも、単精度が遅くなったら、アカンやん…うーん
Dhrystone など、整数性能は、クロック比程度の性能向上。
Raspi1は、ARM11@700MHz で、Raspi2 は、ARM Cortex-A7@1000MHz。
ARM11は、なかなかいい機械だったので、Cortex-A7と比べてもあまり見劣りしない。
浮動小数点演算 性能が気になる。
組込みCPUなので、期待をしてはいけないが…
Raspi1 の FPU は、ARMの VFP で、ショート・ベクトルとか言っているが、
どないもこないも、遅いしろものであった…
Raspi2 のFPUは、また別物。
Raspbian 標準の gcc (gcc 4.6.3) に
CFLAGS = -O4 -mfp=3 -march=armv7-a -mfpu=vfpv3-d16
で、linpack を make。
システムクロックは、1000MHz と 標準の700MHz で計測。
--- 1000MHz ---
take@raspi2% ./linpackc_sp
Enter array size (q to quit) [200]:
Memory required: 158K.
LINPACK benchmark, Single precision.
Machine precision: 6 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.58 86.21% 10.34% 3.45% 156952.375
128 1.16 91.38% 0.00% 8.62% 165836.516
256 2.32 88.79% 1.72% 9.48% 167415.844
512 4.62 89.18% 3.46% 7.36% 164286.562
1024 9.27 87.59% 3.02% 9.39% 167415.984
2048 18.54 88.03% 2.10% 9.87% 168317.594
Enter array size (q to quit) [200]:
Memory required: 158K.
LINPACK benchmark, Single precision.
Machine precision: 6 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.58 89.66% 0.00% 10.34% 169025.500
128 1.16 83.62% 0.00% 16.38% 181223.141
256 2.32 87.50% 4.74% 7.76% 164286.656
512 4.63 89.20% 2.16% 8.64% 166228.547
1024 9.27 88.57% 2.48% 8.95% 166622.547
2048 18.54 88.24% 3.13% 8.63% 166032.109
Enter array size (q to quit) [200]:
take@raspi2% ./linpackc_dp
Enter array size (q to quit) [200]:
Memory required: 315K.
LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.78 87.18% 5.13% 7.69% 122074.074
128 1.54 89.61% 4.55% 5.84% 121232.184
256 3.09 91.59% 2.59% 5.83% 120815.578
512 6.19 90.79% 2.75% 6.46% 121441.566
1024 12.36 91.10% 2.91% 5.99% 121023.523
Enter array size (q to quit) [200]:
Memory required: 315K.
LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.77 90.91% 2.60% 6.49% 122074.074
128 1.55 91.61% 2.58% 5.81% 120401.826
256 3.10 90.97% 2.58% 6.45% 121232.184
512 6.20 90.97% 3.06% 5.97% 120608.348
1024 12.40 91.05% 2.66% 6.29% 121023.523
Enter array size (q to quit) [200]:
--- 700MHz ---
take@raspi2% ./linpackc_sp
Enter array size (q to quit) [200]:
Memory required: 158K.
LINPACK benchmark, Single precision.
Machine precision: 6 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.64 90.63% 1.56% 7.81% 148971.734
128 1.29 88.37% 2.33% 9.30% 150245.031
256 2.57 87.94% 2.72% 9.34% 150889.688
512 5.14 88.13% 3.11% 8.75% 149924.641
1024 10.28 88.42% 2.63% 8.95% 150245.156
Enter array size (q to quit) [200]:
Memory required: 158K.
LINPACK benchmark, Single precision.
Machine precision: 6 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.65 89.23% 4.62% 6.15% 144087.297
128 1.30 89.23% 1.54% 9.23% 148971.484
256 2.59 88.03% 2.70% 9.27% 149605.656
512 5.19 91.71% 2.12% 6.17% 144383.328
1024 10.37 90.26% 2.12% 7.62% 146794.453
Enter array size (q to quit) [200]:
take@raspi2% ./linpackc_dp
Enter array size (q to quit) [200]:
Memory required: 315K.
LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.86 93.02% 2.33% 4.65% 107186.992
128 1.72 92.44% 2.33% 5.23% 107844.581
256 3.45 91.01% 2.90% 6.09% 108510.288
512 6.87 90.83% 3.20% 5.97% 108846.233
1024 13.75 92.95% 1.38% 5.67% 108426.626
Enter array size (q to quit) [200]:
Memory required: 315K.
LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.86 93.02% 0.00% 6.98% 109866.667
128 1.74 91.38% 1.72% 6.90% 108510.288
256 3.47 89.63% 4.03% 6.34% 108176.410
512 6.95 90.65% 3.02% 6.33% 108010.241
1024 13.90 90.86% 2.66% 6.47% 108176.410
Enter array size (q to quit) [200]:
コア1つで、この性能なら、組込みCPUとしては、まぁ速い。
4コアなので、OpenMP とかで並列に動けば、まぁまぁいいかも知れない。
だが、キャッシュの食い合いとか、内部のバンド幅のせいで、性能が出ないかも知れない。
OpenMP版Linpack も動かしたが、Flops 値が、今は出せていない。
上記で使用したコンパイラ
take@raspi2% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-14+rpi1)
2015/FEB/27 追記
kkojimaさんのコメントにより…
gcc-4.8 に
CFLAGS = -O4 -march=armv7-a -mfpu=vfpv3-d16
で、linpack を makeし計測。
システムクロックは、1000MHzで計測。
単精度はそこはかとなく遅い気がする(700MHzでは、はっきりと遅い)。
が、倍精度は、速いようだ。
これがコンパイラの力か…
でも、単精度が遅くなったら、アカンやん…うーん
--- 1000MHz ---
take@raspi2% ./linpackc_sp
Enter array size (q to quit) [200]:
Memory required: 158K.
LINPACK benchmark, Single precision.
Machine precision: 6 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.57 87.72% 0.00% 12.28% 175786.672
128 1.15 88.70% 2.61% 8.70% 167415.891
256 2.31 88.31% 4.33% 7.36% 164286.578
512 4.60 88.91% 2.39% 8.70% 167415.844
1024 9.20 88.70% 2.83% 8.48% 167018.266
2048 18.41 88.21% 2.82% 8.96% 167815.422
Enter array size (q to quit) [200]:
Memory required: 158K.
LINPACK benchmark, Single precision.
Machine precision: 6 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.58 84.48% 6.90% 8.62% 165835.672
128 1.16 87.07% 3.45% 9.48% 167416.609
256 2.32 88.79% 3.45% 7.76% 164287.234
512 4.65 89.25% 2.80% 7.96% 164287.094
1024 9.28 88.04% 3.02% 8.94% 166425.469
2048 18.57 88.21% 3.02% 8.78% 166031.844
Enter array size (q to quit) [200]:
Memory required: 158K.
LINPACK benchmark, Single precision.
Machine precision: 6 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.58 87.93% 3.45% 8.62% 165839.250
128 1.17 86.33% 2.56% 11.11% 169024.250
256 2.32 87.50% 3.45% 9.05% 166623.000
512 4.64 88.58% 2.80% 8.62% 165836.562
1024 9.29 89.13% 1.94% 8.93% 166228.250
2048 18.57 88.37% 2.85% 8.78% 166032.328
Enter array size (q to quit) [200]: q
take@raspi2% ./linpackc_dp
Enter array size (q to quit) [200]:
Memory required: 315K.
LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.73 91.78% 1.37% 6.85% 129254.902
128 1.46 90.41% 2.05% 7.53% 130212.346
256 2.92 89.04% 2.40% 8.56% 131675.406
512 5.84 90.07% 2.91% 7.02% 129492.940
1024 11.68 89.81% 2.65% 7.53% 130212.346
Enter array size (q to quit) [200]:
Memory required: 315K.
LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.73 89.04% 4.11% 6.85% 129254.902
128 1.46 90.41% 2.74% 6.85% 129254.902
256 2.92 89.73% 3.42% 6.85% 129254.902
512 5.84 89.90% 2.74% 7.36% 129971.657
1024 11.68 89.64% 3.00% 7.36% 129971.657
Enter array size (q to quit) [200]:
Memory required: 315K.
LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.74 89.19% 4.05% 6.76% 127381.643
128 1.47 91.84% 0.68% 7.48% 129254.902
256 2.94 89.12% 3.40% 7.48% 129254.902
512 5.89 90.15% 2.55% 7.30% 128781.441
1024 11.78 89.81% 2.63% 7.56% 129136.211
Enter array size (q to quit) [200]:
Memory required: 315K.
LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.74 90.54% 1.35% 8.11% 129254.902
128 1.47 88.44% 4.08% 7.48% 129254.902
256 2.94 88.44% 3.74% 7.82% 129731.857
512 5.89 89.64% 2.89% 7.47% 129017.737
1024 11.77 89.97% 2.63% 7.39% 129017.737
Enter array size (q to quit) [200]: q
take@raspi2% gcc-4.8 -v
Using built-in specs.
COLLECT_GCC=gcc-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 4.8.2-21~rpi3rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.8.2 (Raspbian 4.8.2-21~rpi3rpi1)
これは、Lispアドベントカレンダー 2014/DEC/22 なのです。
が、ネタ、まだ。無し…
すんません。
が、ネタ、まだ。無し…
すんません。
OpenEL というものがあり…
OpenELの概要
OpenELの概要 2
OpenELというのは、 JASA((社)組込みシステム技術協会) などが絶賛 推進中の規格で、
ロボット用ハードウェアの下まわりを抽象化するレイヤ。
ROSやRTミドルウェアの下位の層を抽象化して、ミドルウェアやアプリケーションの移植性を高める。
あたくしは、JASAの役員などを拝命しており、OpenELのユーザとしてぼちぼちと遊んでいる。
あたくしは、かねてより、 Multi ThreadなBASICインタープリタを作っている。
これは、裸のマイコンに入れて、対話的にI/Oを叩いたり、
マルチ・スレッドで、多数のI/Oを制御するプログラムを簡単に書けるようにするプログラミング言語である。
この MultiThread BASICに、DCモータ制御のプリミティブを追加した。
そのプリミティブは、OpenEL の DCモータ・コンポーネントを介し、DCモータの制御を行う。
OpenELのDCモータの初期化などは、暗黙のうちにBASIC処理系がやってしまう。
よって、追加したのは、
oeltrq ポート,トルク値
だけである。
内部では、OpenELの
elMotorSetTorque_I32(ポート, トルク値 );
を呼び出している。
トルク値が 0～33で逆転、34～66で停止、67～100で正転。
模型用のDCモータは単純な制御しかできませんから。(電圧を変えるとか、パルスで制御とかもできるでしょうが)
BASICインタープリタはC言語で書いてあり、移植性は高い。
DCモータ制御もOpenELを通している。
よって、OpenELをサポートしたプラットフォームならば、
すぐにMultiThread BASICを移植し、BASICからDCモータを制御することが可能である。
せっかくなので、応用例として、
フォトダイオードで、黒い線を読み取って、走る
ライントレーサを作った。
土台は、タミヤの、壁づたいに走るネズミ。
オリジナルは、メカのタッチセンサで、右に走るか、左に走るかを決める。
上記を、光センサとマイコン(BASIC+OpenEL)で作り直して、
黒い線を中心に左右に振りながら、進むようにする。簡単。
あたくしは、1970年代前半の小学校の時に、NHK教育TVの「みんなの科学」でライントレーサをみて、
「マイキット150」の CDS とリレーで、作った。
まだ、マイクロ・プロセッサもなければ、デジタルIC TTL 74シリーズも、アマチュアにはほとんど知られていない頃の話だ。
「マイキット150」は、部品取りになった側面もあるが、楽しいオモチャだった。
あたくしは、「電子ブロック」よりも、圧倒的に「マイキット」派である。
「マイキット150」の太陽電池は、今でも大切に取ってある。
ライントレーサは、極めて簡易な装置なので、BASICのプログラムも簡単である。
上記中の "&@"は、フォト・ダイオードを接続したADコンバータからの入力を読み込む引数なし関数である。
MultiThreadBASIC+OpenELが動いているチップは、
PIC32MX250 (MIPSコア@50MHz、ROM128KB, RAM32KB)
秋月で360円
である。
PIC32MX220 (MIPSコア@40MHz、ROM32KB, RAM8KB)
秋月で250円
は、残念ながらROMが足りないので、
マルチ・スレッドではない普通のTiny BASICにOpenELをつないで動かしている。
ライントレーサは、このPIC32MX220のシングル・スレッドBASICでも動く。
回路図(2014/OCT/11追記)
OpenELの概要
OpenELの概要 2
OpenELというのは、 JASA((社)組込みシステム技術協会) などが絶賛 推進中の規格で、
ロボット用ハードウェアの下まわりを抽象化するレイヤ。
ROSやRTミドルウェアの下位の層を抽象化して、ミドルウェアやアプリケーションの移植性を高める。
あたくしは、JASAの役員などを拝命しており、OpenELのユーザとしてぼちぼちと遊んでいる。
あたくしは、かねてより、 Multi ThreadなBASICインタープリタを作っている。
これは、裸のマイコンに入れて、対話的にI/Oを叩いたり、
マルチ・スレッドで、多数のI/Oを制御するプログラムを簡単に書けるようにするプログラミング言語である。
この MultiThread BASICに、DCモータ制御のプリミティブを追加した。
そのプリミティブは、OpenEL の DCモータ・コンポーネントを介し、DCモータの制御を行う。
OpenELのDCモータの初期化などは、暗黙のうちにBASIC処理系がやってしまう。
よって、追加したのは、
oeltrq ポート,トルク値
だけである。
内部では、OpenELの
elMotorSetTorque_I32(ポート, トルク値 );
を呼び出している。
トルク値が 0～33で逆転、34～66で停止、67～100で正転。
模型用のDCモータは単純な制御しかできませんから。(電圧を変えるとか、パルスで制御とかもできるでしょうが)
BASICインタープリタはC言語で書いてあり、移植性は高い。
DCモータ制御もOpenELを通している。
よって、OpenELをサポートしたプラットフォームならば、
すぐにMultiThread BASICを移植し、BASICからDCモータを制御することが可能である。
せっかくなので、応用例として、
フォトダイオードで、黒い線を読み取って、走る
ライントレーサを作った。
土台は、タミヤの、壁づたいに走るネズミ。
オリジナルは、メカのタッチセンサで、右に走るか、左に走るかを決める。
上記を、光センサとマイコン(BASIC+OpenEL)で作り直して、
黒い線を中心に左右に振りながら、進むようにする。簡単。
あたくしは、1970年代前半の小学校の時に、NHK教育TVの「みんなの科学」でライントレーサをみて、
「マイキット150」の CDS とリレーで、作った。
まだ、マイクロ・プロセッサもなければ、デジタルIC TTL 74シリーズも、アマチュアにはほとんど知られていない頃の話だ。
「マイキット150」は、部品取りになった側面もあるが、楽しいオモチャだった。
あたくしは、「電子ブロック」よりも、圧倒的に「マイキット」派である。
「マイキット150」の太陽電池は、今でも大切に取ってある。
ライントレーサは、極めて簡易な装置なので、BASICのプログラムも簡単である。
-- ライントレーサのBASICソース
5 'PIC32 OpenEL Motor ADC
6 'oeltrq 0,50:oeltrq 1,50
10 do
20 if &@<40 oeltrq 0,1:oeltrq 1,50:goto 50
30 oeltrq 0,50:oeltrq 1,1:goto 50
50 while 1
-- EOF
上記中の "&@"は、フォト・ダイオードを接続したADコンバータからの入力を読み込む引数なし関数である。
MultiThreadBASIC+OpenELが動いているチップは、
PIC32MX250 (MIPSコア@50MHz、ROM128KB, RAM32KB)
秋月で360円
である。
PIC32MX220 (MIPSコア@40MHz、ROM32KB, RAM8KB)
秋月で250円
は、残念ながらROMが足りないので、
マルチ・スレッドではない普通のTiny BASICにOpenELをつないで動かしている。
ライントレーサは、このPIC32MX220のシングル・スレッドBASICでも動く。
回路図(2014/OCT/11追記)
映画「舞妓はレディ」が、まわりの人に評判がいい。
なので、京都で「舞妓はレディ」を観てきた。
オードリーヘプバーンの「マイフェアレディ」のパクリ。
(あたしが割と好きな映画だ。オードリーヘプバーンが、歌が下手で口パクとかも楽しい)
日本でミュージカルとか、ようやるわ。
悪くはなかったが… 歌わなくても、ストーリー持つやろ。
とはいえ、私には、真ん中あたりが、もたつき感があり、寝るかと思たわ。
「京都で、雨は、だいたい盆地に降る?」というのが、「スペインでは、雨は主に平地に降る」のオマージュでよろしかったなぁ。
言語の映画ということで、ちゃんと京都弁をしゃべってるかチェックや。
(あたくしは、大阪生まれの尼崎育ちやっ。京都では呑んでるだけ)
岸辺一徳は、京都の旦那とかやらせても、いつも似合ってるなぁ。そもそも京都人らしいしな。
(沢田研二も京都人やで。と書いても、そのつながりである「ザ・ タイガース」が若い人には分からんやろwww)
29歳まで舞妓(本当は舞妓は18歳まで)をやってるという役の田畑智子は、祇園の料亭の娘らしい。ドラマ「ファーストクラス」でも、怖くて上手い関西弁喋ってたし。
竹中直人は、芝居は上手いが、京都弁は残念。なんでもかんでも竹中直人を使うのは、いかがなものだろう。
言語学の先生で、どの地方の言葉でも操るという長谷川博己だが、全然、喋れてなかったで。
そこの学生で、京都のお茶屋の息子という濱田岳は、酷かった。京都弁をしゃべれる役者を使うべきやろ。
その他の脇を固めてる人は、ちゃんとした花街らしい言葉をしゃべってた。なかなかやるなー
ヒロインは、最後はちゃんと京都花街弁を喋ってた。
本物の舞妓ちゃんも、ほぼ地方出身者なので、練習すれば、普通、喋れるようになるのだろう。
「下八軒」という「上七軒」をもじった場所が舞台だが、
街のイメージは、祇園東。
ちなみに、上七軒の方が格は高いそうだが、西陣が不景気なので…
あたくしは、とても若いときに、上七軒のビアガーデンの只券を西陣の旦那からもらって、行ったきり。
舞台の街は、セットだが、「祇園東」のこのあたり をイメージして作ったと思われ。
祇園東の白川の橋のあたり。
東側に橋。西側に、小さいお堂がある。東から橋を渡ってきたら、よろしいよ。
南側の橋の辺りが、風情がある。
節分の祇園は、「おばけの日」で、コスプレするのは本当。
祇園のクラブのホステスも多少コスプレする。
(紋付で正装してはる芸子はんも居はる)
だいぶ前の節分の日に、錦の超絶に安い立ち飲み(ただし客筋はとても良い)で有名な「松川酒店」に、
友人の社長と呑みに行ったら…
芸子はんを ぎょうさん連れた旦那が呑みに来てはった。旦那は、「裸の大将」のカッコしてた。よう似合てはった(2月やのに)。
ちなみに、江戸の芸者さんと、銀座のホステスは、節分は、紋付で正装するのみらしい。
オーディオに触れないようにしてきて、あれこれ聴いたことがないわたくし…
本当のお家(?)では、昔(1990年ごろ)に、買った
「テクニクス」のTechnics SE-M100 デジタルストレートアンプ に、
JBL Control One という構成
詳しくは、この日記にあり。
正月休みに、退屈過ぎ、東京の下宿にはまったくオーディオが無いのも寂しくなった。
(PCと安物のアンプ付きスピーカでネットラジオを聴いているだけだった。それでもまぁいいのだけど)
オーディオをなんとかしよう、と思い立つ。
そういえば、お友達の暇村さんが、楽しそうに、秋月のUSB DAC を作って、日経Linuxでも記事 を書いておられたなぁ。
暇村さんのUSB DAC 製作詳細
その流れで、OSSコンソーシアム 組込み部会 女子部で、秋月 USB-DAC製作会 もやったなぁ。(私は主催者の一員なのだが、残念ながら、日程が合わず、欠席)
秋月USB-DACは、ネット上でも評判いいんだなぁ、知らなかった…
というわけで、
秋月のUSB DAC キット は作った。
このキットは、
回路図 を見ると、
音のアナログ信号を通る所のコンデンサだけは、秋月の標準版でも、ちゃんといいコンデンサを使っている。
電源やらのコンデンサにこだわってもいいが、部品が余るのもアレなので、標準のままでいいや。
そして、ネット徘徊していると…
まともな測定器を使った人が、秋月USB-DACの出力にローパス・フィルタは入れた方がいいんじゃない と、書いているので、
そのページの最後にあった、ローパス・フィルタをそのまま作ってつないだ。
一応、ケースにも入れた。
わたしくは、金属ケースとかの加工は下手くそだし、やっぱり金属ケースは高い。
でも、シールドはしたいから、やっぱりオーディオのケースは金属ですね。
ちゃんと、ケースにアースしてます。電気の基本。
(マイコンなどは、ノイズ出しまくりOK なので、お菓子の紙の箱や、100円ショップのクリップのプラッチックの入れ物などでお気楽)
でも、アンプを作った方が楽しいんじゃね?
部品を買い集めたり、アナログ基板のことを考えるのは面倒なので、キットでいいや。
と思い、アンプ製作キットを求めて、ネット徘徊。
そこで一つ分かったことは…
完成品の中華アンプが数千円(2500円～3000円)程度で売られていて、
なんだか、それが結構いい音らしい。
(当たり前だけど)完成品なので、それなりにかっこいいケースに入ってるしな～
自分でアンプを作っても、ケースが高い。
本当のオーディオらしい高級感のあるケースは、1000円～数千円になってしまう。
スイッチとボリュームのつまみも、カッコいいのは、かなり高い。
これならば、ケースを買うつもりで、中華アンプを買ってもいいだろう、と思ってしまいました。
なので、キットで安直にアンプを作る、という夢は潰えた。
こうやって、アメリカ人も、日本製品にやられていったんだろうなぁ。
(そして、日本人は、現在、中国製品にやられつつ…)
中華アンプを調べるに…
Tripath社という半導体会社の TA2020 というチップを使ったものが、えらい安いのに、いい音が出るらしい。
Lepai社の LP2020Aというアンプが、2500円位(2014/JAN上旬 電源なし)だったので、購入を決断。
このLP2020A、トーン・コントロールという、1970年代の機能を搭載し、安い。
電源スイッチの安っぽさは、どうにかしろよ、と思うが、
フロントパネルは、工作の下手な私でも、全部作りなおせるだろう、などと、
ケースは部品取り用にも、考えつつ…
そもそも車載用らしいので、トーン・コントロールがついているらしい。
自動車というオーディオに向かない空間で、音をユーザが自分の好みに変える、というのは、健全ですな。
ただ、トーンコントロールをONにすると、音が濁るです。
トーン・コントロールのために、オペアンプが入って、そのオペアンプの色が入るんでしょね。
LP2020 参考回路図
Lepai LP2020をどこから買うか、とか、改造情報などを求めていると…
North Flat Japan というマニアックな会社が、LP2020を扱っており。
NFJ は、LP2020の別注版を作らせており、部品なども変えているらしい。
NFJのブログがおもしろい。
「ボリュームの軸がアースされてないことが発覚」とかは、ちょっと笑った。
Lepai社は、部品は安物だし、素人まるだし でおもしろい。
NFJ社の取り組みがいいので、Lepai LP2020は、
NFJ 社の LP2020 第7ロット というのを買った。
LP2020は、すぐに到着したので、 JBL Contol-One
に接続。
ちなみに、このJBL Contol-Oneは、今回、新たに買ったもの。
(スピーカの慣らし(エージング)もやりつつ聴いてみている)
1990年ごろ、なにげに買ったControl Oneが、不朽の名機になっていて驚いたですよ。 IT Media: 定番スピーカーはどう変わった？ JBL「CONTROL ONE」を聴く
PCやら、Raspiやら、Cubox から、USB経由で
秋月USB-DAC(ローパスフィルタ入り)へ、その出力を
LP2020 ＋ JBL Control One
私は、CDしか聴かなかったし、デジタル・ストレート・アンプしか聴いてないので、
偉そうに音を語る資格はないのですが…
(現在の音源は、大昔に iPod Shuffle に入れた音と、ネットラジオが主。CDが手元に無いのですなぁ)
デジタルらしい、色のついてない、
クリアでまっすぐした音だと思います。
低音から高温まで、まんべんなく出ている感じ。
(ある友人は、「低音が出てない」と言ってはりますが、私的には、ちょうどいいんじゃないかと…)
Raspberry Pi に、秋月USB-DAC, LP2020, JBL Control One。
iCatさんからお借りしている Cubox1 に、秋月USB-DAC, LP2020, JBL Control One。
本当のお家(?)では、昔(1990年ごろ)に、買った
「テクニクス」のTechnics SE-M100 デジタルストレートアンプ に、
JBL Control One という構成
詳しくは、この日記にあり。
正月休みに、退屈過ぎ、東京の下宿にはまったくオーディオが無いのも寂しくなった。
(PCと安物のアンプ付きスピーカでネットラジオを聴いているだけだった。それでもまぁいいのだけど)
オーディオをなんとかしよう、と思い立つ。
そういえば、お友達の暇村さんが、楽しそうに、秋月のUSB DAC を作って、日経Linuxでも記事 を書いておられたなぁ。
暇村さんのUSB DAC 製作詳細
その流れで、OSSコンソーシアム 組込み部会 女子部で、秋月 USB-DAC製作会 もやったなぁ。(私は主催者の一員なのだが、残念ながら、日程が合わず、欠席)
秋月USB-DACは、ネット上でも評判いいんだなぁ、知らなかった…
というわけで、
秋月のUSB DAC キット は作った。
このキットは、
回路図 を見ると、
音のアナログ信号を通る所のコンデンサだけは、秋月の標準版でも、ちゃんといいコンデンサを使っている。
電源やらのコンデンサにこだわってもいいが、部品が余るのもアレなので、標準のままでいいや。
そして、ネット徘徊していると…
まともな測定器を使った人が、秋月USB-DACの出力にローパス・フィルタは入れた方がいいんじゃない と、書いているので、
そのページの最後にあった、ローパス・フィルタをそのまま作ってつないだ。
一応、ケースにも入れた。
わたしくは、金属ケースとかの加工は下手くそだし、やっぱり金属ケースは高い。
でも、シールドはしたいから、やっぱりオーディオのケースは金属ですね。
ちゃんと、ケースにアースしてます。電気の基本。
(マイコンなどは、ノイズ出しまくりOK なので、お菓子の紙の箱や、100円ショップのクリップのプラッチックの入れ物などでお気楽)
でも、アンプを作った方が楽しいんじゃね?
部品を買い集めたり、アナログ基板のことを考えるのは面倒なので、キットでいいや。
と思い、アンプ製作キットを求めて、ネット徘徊。
そこで一つ分かったことは…
完成品の中華アンプが数千円(2500円～3000円)程度で売られていて、
なんだか、それが結構いい音らしい。
(当たり前だけど)完成品なので、それなりにかっこいいケースに入ってるしな～
自分でアンプを作っても、ケースが高い。
本当のオーディオらしい高級感のあるケースは、1000円～数千円になってしまう。
スイッチとボリュームのつまみも、カッコいいのは、かなり高い。
これならば、ケースを買うつもりで、中華アンプを買ってもいいだろう、と思ってしまいました。
なので、キットで安直にアンプを作る、という夢は潰えた。
こうやって、アメリカ人も、日本製品にやられていったんだろうなぁ。
(そして、日本人は、現在、中国製品にやられつつ…)
中華アンプを調べるに…
Tripath社という半導体会社の TA2020 というチップを使ったものが、えらい安いのに、いい音が出るらしい。
Lepai社の LP2020Aというアンプが、2500円位(2014/JAN上旬 電源なし)だったので、購入を決断。
このLP2020A、トーン・コントロールという、1970年代の機能を搭載し、安い。
電源スイッチの安っぽさは、どうにかしろよ、と思うが、
フロントパネルは、工作の下手な私でも、全部作りなおせるだろう、などと、
ケースは部品取り用にも、考えつつ…
そもそも車載用らしいので、トーン・コントロールがついているらしい。
自動車というオーディオに向かない空間で、音をユーザが自分の好みに変える、というのは、健全ですな。
ただ、トーンコントロールをONにすると、音が濁るです。
トーン・コントロールのために、オペアンプが入って、そのオペアンプの色が入るんでしょね。
LP2020 参考回路図
Lepai LP2020をどこから買うか、とか、改造情報などを求めていると…
North Flat Japan というマニアックな会社が、LP2020を扱っており。
NFJ は、LP2020の別注版を作らせており、部品なども変えているらしい。
NFJのブログがおもしろい。
「ボリュームの軸がアースされてないことが発覚」とかは、ちょっと笑った。
Lepai社は、部品は安物だし、素人まるだし でおもしろい。
NFJ社の取り組みがいいので、Lepai LP2020は、
NFJ 社の LP2020 第7ロット というのを買った。
LP2020は、すぐに到着したので、 JBL Contol-One
に接続。
ちなみに、このJBL Contol-Oneは、今回、新たに買ったもの。
(スピーカの慣らし(エージング)もやりつつ聴いてみている)
1990年ごろ、なにげに買ったControl Oneが、不朽の名機になっていて驚いたですよ。 IT Media: 定番スピーカーはどう変わった？ JBL「CONTROL ONE」を聴く
PCやら、Raspiやら、Cubox から、USB経由で
秋月USB-DAC(ローパスフィルタ入り)へ、その出力を
LP2020 ＋ JBL Control One
私は、CDしか聴かなかったし、デジタル・ストレート・アンプしか聴いてないので、
偉そうに音を語る資格はないのですが…
(現在の音源は、大昔に iPod Shuffle に入れた音と、ネットラジオが主。CDが手元に無いのですなぁ)
デジタルらしい、色のついてない、
クリアでまっすぐした音だと思います。
低音から高温まで、まんべんなく出ている感じ。
(ある友人は、「低音が出てない」と言ってはりますが、私的には、ちょうどいいんじゃないかと…)
Raspberry Pi に、秋月USB-DAC, LP2020, JBL Control One。
iCatさんからお借りしている Cubox1 に、秋月USB-DAC, LP2020, JBL Control One。
わたくしは、ラジオ小僧でありながら、子供のころからオーディオというものは触らないようにしてきた。
オーディオって、お金かかりそうだもん、というのが理由。
あれこれ聴くと、迷いが出そうなので、あれこれ聴いたことがない。
本当のお家(?)では、昔(1990年ごろ)に、買った、
「テクニクス」のTechnics SE-M100 デジタルストレートアンプ
を、今も使ってます。
この SE-M100 は、1990年ごろ、「テクニクス」のブランドが廃止になり「テクニクス」ブランドの製品が安売りされているときに、新品を3万円ぐらいで買った。
(後に、「テクニクス」ブランドが復活するとは、アレですな～)
SE-M100は、最終段のDACがそのまま出力になり、
それまでの前段はすべてデジタルという、変わった(?)アンプ。
色の付きようがない構成。
同時期に、 JBL Contol-One
を買って、SE-M100につないで、CDばっかり聴いてた。
このほど、安くてまぁまぁなスピーカを求めて、ネット徘徊したら、
なんと、24年位前に、なにげなく買った JBL Contol-One が、不朽の名機として、好評ではないか。
IT Media: 定番スピーカーはどう変わった？ JBL「CONTROL ONE」を聴く
ということで、また、 JBL Contol-One を買ってしまった。
昔のモデルは、エンブレムのバッジがオレンジ色だったのが、
新型は、白になってる。
オーディオって、お金かかりそうだもん、というのが理由。
あれこれ聴くと、迷いが出そうなので、あれこれ聴いたことがない。
本当のお家(?)では、昔(1990年ごろ)に、買った、
「テクニクス」のTechnics SE-M100 デジタルストレートアンプ
を、今も使ってます。
この SE-M100 は、1990年ごろ、「テクニクス」のブランドが廃止になり「テクニクス」ブランドの製品が安売りされているときに、新品を3万円ぐらいで買った。
(後に、「テクニクス」ブランドが復活するとは、アレですな～)
SE-M100は、最終段のDACがそのまま出力になり、
それまでの前段はすべてデジタルという、変わった(?)アンプ。
色の付きようがない構成。
同時期に、 JBL Contol-One
を買って、SE-M100につないで、CDばっかり聴いてた。
このほど、安くてまぁまぁなスピーカを求めて、ネット徘徊したら、
なんと、24年位前に、なにげなく買った JBL Contol-One が、不朽の名機として、好評ではないか。
IT Media: 定番スピーカーはどう変わった？ JBL「CONTROL ONE」を聴く
ということで、また、 JBL Contol-One を買ってしまった。
昔のモデルは、エンブレムのバッジがオレンジ色だったのが、
新型は、白になってる。
これは、 カーネル/VM Advent Calendar 2013 の DEC/21 です。
とりあえず、書きかけで公開 (^^;
いにしえ(1977年発表)の言語として Robot言語 というものがあり。
シェルピンスキー曲線
PCが普及しておらず、グラフィック機能が珍しいときに、出た言語。
しいて関数型と言えば関数型だが、変数が一つしかなく、極めて限定された言語。
リカーシブ・コールが前提。
なので、ループも、リカーシブに記述。
下の絵が、2関数が互いに呼び合う無限ループの例。
ループをリカーシブに書くということは、インタープリタは、テールリカーシブ・インタープリタであって欲しい。
Robot言語は、極めて単純な言語なので、実行系をテールリカーシブ・インタープリタとして実現するのは、容易である。
私が、大昔に、Mac用にCで書いたものがあるはずだが、ソースごと失った。
ケータイ用のJavaの出始め("KVM"と呼ばれた) に、KVM用に書いたソースは、いまだに公開中。
Krobot として公開中。
このソースは、素朴な仮想機械のインタープリタである。
と見せかけて、関数呼び出しの部分が、テールリカーシブ・インタープリタになっている。
そこだけ、解説をしたい…
… といいつつ、とりあえず、ここまでで公開。(^^;
すんません > 世界
ここから、2014/OCT/19 追記 (10ヶ月以上、経ってしまったか)
昨日の、kernel/VM つくば にて、「Robot言語と末尾再帰インタープリタ」というLighting Talkをしてきた。
「資料スライド」
スライドに書いてあるのだが、要するに、
・一命令ていどしか見ない、(仮想機械)インタープリタで、末尾再帰 最適化を行う方法があり、
それでインタープリタを作ってる。
・大事なことは、新しい関数を見つけて、それを呼び出すときに、不要な情報はセーブ(スタックへpush)しない。
・そのために、新しい関数を呼ぶ前に、ほんの少しだけ先読みして、現在のプログラム・カウンタの指しているところが、呼び出し元の関数の末尾かどうかを確認。
もし、末尾であれば、そこに戻ってきて続ける必要が無い。よって、情報をセーブ(push)しない。
・極めて簡単であるが、それによって、Continuation Passingになる。
私のKRobot(と、今回、やっとX Window に持ってこれた Robot言語インタープリタ)のソースでは、
exeq()という関数が、機械の一命令を実行する関数である。
その最後あたり(switch文のdefault)が、ユーザ定義関数から、別な関数を呼び出す部分である。
そこで、新しい関数を呼び出す直前に、末尾か(やることがあるか?)を、CT[Pc]が'\0'か、否かで判定し、
末尾なら push をサボって、最適化している。
(CTは、ユーザ定義関数のボディを保持。Pcは、プログラム・カウンタで、次に実行する命令を指している)
以上のような、構造のインタープリタを、
「テール・リカーシブ・インタープリタ(末尾再帰インタープリタ)」という。
スタックを無駄遣いしないので、末尾再帰による無限ループでも、スタックが減らず、永久にループしつづける。
Schemeは言語仕様書に、インタープリタは、テール・リカーシブ・インタープリタとして実現することとされている。
PrologやSmalltalkなどのコンパイルド・コードを実行する仮想機械インタープリタも、テール・リカーシブ・インタープリタとして実現されることが通常である。
X window版のRobotのソースは、そのうち公開するであろう。
しかし、MacでRobotインタープリタを作ったのが、1988 or 1989年ごろだったが、成長してないなぁ。
というか、Mac版は、テキスト編集とインタープリタの統合環境だったので、どんどん退化してるやん。(涙)
とりあえず、書きかけで公開 (^^;
いにしえ(1977年発表)の言語として Robot言語 というものがあり。
シェルピンスキー曲線 PCが普及しておらず、グラフィック機能が珍しいときに、出た言語。
しいて関数型と言えば関数型だが、変数が一つしかなく、極めて限定された言語。
リカーシブ・コールが前提。
なので、ループも、リカーシブに記述。
下の絵が、2関数が互いに呼び合う無限ループの例。
ループをリカーシブに書くということは、インタープリタは、テールリカーシブ・インタープリタであって欲しい。
Robot言語は、極めて単純な言語なので、実行系をテールリカーシブ・インタープリタとして実現するのは、容易である。
私が、大昔に、Mac用にCで書いたものがあるはずだが、ソースごと失った。
ケータイ用のJavaの出始め("KVM"と呼ばれた) に、KVM用に書いたソースは、いまだに公開中。
Krobot として公開中。
このソースは、素朴な仮想機械のインタープリタである。
と見せかけて、関数呼び出しの部分が、テールリカーシブ・インタープリタになっている。
そこだけ、解説をしたい…
… といいつつ、とりあえず、ここまでで公開。(^^;
すんません > 世界
ここから、2014/OCT/19 追記 (10ヶ月以上、経ってしまったか)
昨日の、kernel/VM つくば にて、「Robot言語と末尾再帰インタープリタ」というLighting Talkをしてきた。
「資料スライド」
スライドに書いてあるのだが、要するに、
・一命令ていどしか見ない、(仮想機械)インタープリタで、末尾再帰 最適化を行う方法があり、
それでインタープリタを作ってる。
・大事なことは、新しい関数を見つけて、それを呼び出すときに、不要な情報はセーブ(スタックへpush)しない。
・そのために、新しい関数を呼ぶ前に、ほんの少しだけ先読みして、現在のプログラム・カウンタの指しているところが、呼び出し元の関数の末尾かどうかを確認。
もし、末尾であれば、そこに戻ってきて続ける必要が無い。よって、情報をセーブ(push)しない。
・極めて簡単であるが、それによって、Continuation Passingになる。
私のKRobot(と、今回、やっとX Window に持ってこれた Robot言語インタープリタ)のソースでは、
exeq()という関数が、機械の一命令を実行する関数である。
その最後あたり(switch文のdefault)が、ユーザ定義関数から、別な関数を呼び出す部分である。
そこで、新しい関数を呼び出す直前に、末尾か(やることがあるか?)を、CT[Pc]が'\0'か、否かで判定し、
末尾なら push をサボって、最適化している。
(CTは、ユーザ定義関数のボディを保持。Pcは、プログラム・カウンタで、次に実行する命令を指している)
int
exeq() // 1命令を実行する
{
n= term();
switch((ccc=CT[Pc++])){
case 'f' :
x1=x + n*v*step; y1=y + n*u*step;
drawLine(x,y, x1,y1, 0);
x=x1; y=y1;
break;
:
:
default: /* ユーザ定義関数 */
top= defun[ccc-'a'];
/* 末尾再帰 最適化可能な時は、pushしない
ユーザ関数定義の末尾、すなわち、後に実行すべきものが何もない */
if(n!=1 || CT[Pc]!='\0'){ /*やるべきことがある時、セーブ*/
Context c;
c.n=n; c.top=top; c.pc=Pc; c.ct=CT;
stk_push(&c);
} // やることが無いときは、何もしない。最適化できた!!
CT= top; Pc=0;
//printf(" userFunc %c CT=%x ",ccc,CT);
}
}
以上のような、構造のインタープリタを、
「テール・リカーシブ・インタープリタ(末尾再帰インタープリタ)」という。
スタックを無駄遣いしないので、末尾再帰による無限ループでも、スタックが減らず、永久にループしつづける。
Schemeは言語仕様書に、インタープリタは、テール・リカーシブ・インタープリタとして実現することとされている。
PrologやSmalltalkなどのコンパイルド・コードを実行する仮想機械インタープリタも、テール・リカーシブ・インタープリタとして実現されることが通常である。
X window版のRobotのソースは、そのうち公開するであろう。
しかし、MacでRobotインタープリタを作ったのが、1988 or 1989年ごろだったが、成長してないなぁ。
というか、Mac版は、テキスト編集とインタープリタの統合環境だったので、どんどん退化してるやん。(涙)
これは、Lisp Advent Calendar 2013 のDEC/05 です。
1981年だか82年だか、僕の居た大学のコンピュータクラブで、Lispを作るのが流行った。
5人ぐらいで、バラバラに オレオレLisp を作った。
Lispというものは、readerがもっとも難しいと思う。
昔風の eval は、すぐにできる気がする。
gcは、なかなかバグが取れない。C言語で書くと、Cのローカル変数や、Cのスタックに生きてるconsへのポインタが乗るが、そこはスキャンできなかったりするのが、主な原因だろう。
当時、あたくしは、BASICでLispを書いていた。
8bit機である。私は6809@1MHz の載ったBASIC Master Level3 を使っていた。
RAMは、8～48KBytes ぐらいの機械が普通だった。
BASIC master Level3は、30万円ぐらいして、5inch 片面フロッピ・ドライブとそのI/Fカードが35万円ぐらいした気がする…
さて、現在…
32bit MIPS core のPIC32が200円程度である。
PIC32MX220は、ROM:32K Bytes, RAM:8K Bytes を内蔵。
クロック周波数は40MHzで、1.56 DhrystoneMIPS。
ARM Cortex-M0 CoreのLPC1114が110円程度である。
LPC1114FN28 は、ROM:32K Bytes, RAM:4K Bytes
クロック周波数は50MHz(最大),内臓CR発信器で12MHzで使用。
32bit Coreで、40MHz って、なんぼほど速いねん!?!
RAMも4KB あれば、なんでも(?)できるぜっ。(そうか?)
そこで、極小 Lispマシンをつくろう、と思い立ったです。
BASIC インタープリタも動くんですけど、Lispインタープリタも動く。
(Flash ROMは、焼き直す)
Lisp処理系の名前「Lise:the Lisp Engine」というのは、冒頭の1981年頃の オレオレLispに付けた名前。
当時から リーゼ(liese)というシャンプー があり、その名前にインスパイアされ、Liseという女の子の名前にした。(爆笑)
まず、PIC32のマシン
PIC32の方は、液晶は Aitendo で買った 白黒の FSTN グラフィック液晶
FSTN液晶モジュール（128×64/SPI）[AD-12864-SPI]
これを、PIC32のGPIOにつないで、ソフトウェアでGPIOを制御し、SPI 的なタイミングで、コマンドを書き込む。
液晶のつなぎやすさのみを優先し、GPIOのピンを選択。
CPUチップの他には、コンデンサしか載っていない。可変抵抗は、LCDのバックライトの明るさ調整。
ネットに、8x5 ドットのフォントが落ちていたので、とりあえず、それを入れて、文字表示を行う。
(こういう液晶は、縦8ドットを1ワードとしてアクセスする。縦8ドットのフォントは、使いやすい。
当然、液晶を90°回転させた状態でマウントするなら、縦横は入れ替わるが…)
極小マシンに、キーボードは付けられないのでスイッチを何個にするか考える。
ゲームボーイ配列が面白いだろう、と、思って作ったが…
完成品を、@zick_minoh の後輩(僕の後輩でもある)の学生に見せたところ、
「だいぶ前に、zickさんが、ポケステで動かしてたのと同じですか?」と素直に言われて、驚いた。
そういえば、そんなのあったなぁ…
たぶん、以前に見た このポケステLispに、発想が引っ張られてしまったんだろうなぁ。
うーん、つまらない。
しかし、筐体を、100円ショップで売られている画鋲のケースにしたり、それにアロンアルファでスイッチを付けたり、結構、苦労しているのだ。
大体においては、ちびマシンは、入れ物が大事なのである。
だらだらした動画(無音)をあげました(2013/DEC/11)
zick君の ポケステLisp
ポケステでLispインタプリタ動かしてみた
ポケステでLispインタプリタ動かしてみた on ニコ動
ポケステは、RAMが2KBか、頑張ってるなぁ…
でも、zickは、入力補助が「コンプリーション」とか言ってるな。
こちらは、上ボタンを押すと、シンボルテーブルから、シンボルを取ってきて、入力候補にするぞ。
一回入力したシンボルは、シンボルテーブルにあるし、コンプリーションより楽なはず。
アプリケーションごとに、リセットすると、シンボルテーブルが肥大化せず、割と入力が楽。
ニュートラル状態から、下ボタン押下は、通常の1文字が候補に出る。
() '\177?+-*/0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!\"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~
という順序で候補文字が出る。
スイッチ入力と並行して、シリアル・ラインからの文字入力も受け付ける。
液晶に表示される8x5ドットの文字は、極小過ぎて、オジサンには極めて読みづらい。
なので、通常は、シリアルラインから入力して、楽しむ。(^^;
表示は、液晶とシリアルラインに同じものが出力される。
free cell(利用可能なcons cell)は、800個程度あり、まぁまぁ実用的。
液晶無しの回路図などは、 過去のブログで
ARM LPC1114 のマシンは、液晶はつないでいるが、入力はシリアルラインのみ。
液晶には、Lispプログラムから自由に表示できる。
筐体になるケースとか、入力方法を検討中。
ポケステLispの轍は踏むまい。www
こちらは、4KBしかメモリがないので、
free cell(使用可能なcons)は、39個。
これでは、デモ以外、何もできない。
まぁ、そういうもんだ。＼(^^;／
この機械の液晶は、Aitendoで売られている下記
ノキア液晶5110（SPI）[M-LCD5110-PCB]
以前は、基板と液晶がバラになってて、500円ぐらいのものが売られており、僕はそれを買って使用。
液晶無しの回路図などは、 過去のブログで
今回の処理系は、生のポインタを使用しない。
メモリが少ないのに、32bitのポインタを使用すると非常に非効率である。
なので、consは、C言語の配列上に取る。
consのcar,cdrには、配列のオフセットを入れて表現。
オフセットは、unsigned short (16bit)。
tag を3bitにして、オフセット(ポインタ)の最上位3bitに入れている。
シンボルテーブルは、現在は、consとは別な領域に取っている。
fix num(小さな整数)が、13bitなので、符号付きで -4096～ +4095 しか表現できず、
すぐにオーバーフローして、やや辛い。
小規模組込用途で、使えるような、使えないような、ぎりぎりの線上。(^^;
appendできます
Lise>>(set! ap (lambda(x y) (cond ((eq? x nil) y)(#t (cons(car x)(ap(cdr x) y))))))
closure-40FC
Lise>>(ap '(a b) '(z x))
gc (a b z x )
Lise>>
クロージャなんぞも、一応ちゃんとつけてある。
Lise>>(set! aaa (let (z) (set! z 0) (lambda (x) (set! z (cons x z)))))
closure-421C
Lise>>(aaa 'asd)
gc (asd .0)
Lise>>(aaa 'asd)
(asd asd .0)
Lise>>(aaa 'asd)
(asd asd asd .0)
Lise>>(aaa 'asd)
(asd asd asd asd .0)
Lise>>(aaa 'asd)
(asd asd asd asd asd .0)
Lise>>(aaa 'asd)
(asd asd asd asd asd asd .0)
Lise>>(aaa 'asd)
gc (asd asd asd asd asd asd asd .0)
Lise>>z
NIL
Lise>>
最後に、z を見ているのは、グローバルな変数zに (asd asd asd asd asd asd asd .0)
が入っていないことを確認している。
ちなみに、Scheme風のシンボル名を使っているが、継続が無いので、ただの昔Lisp。
お粗末。