たけおか ぼちぼち日記

たけおか ぼちぼち日記

思いついたらメモ

Raspberry Pi Zero 2 W をやっと入手した。
(Zero 2 とか聞くと、太陽電池で動く (キカイダー)「ゼロ・ワン」兄さんが、後から出そうな気がする 昭和世代)

OSは64bit, 32bitとも、現状 最新の
"Linux xxxx 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux"

・メモリについて

メモリは、512 MBytesで、寂しい。
メモリが少ないので、32bit OSで使ったほうが、メモリは有効に使えるだろう。
下記のように、32bitOSは、少しはメモリ消費が少ない。
-- 起動直後

32bit$ free
total used free shared buff/cache available
Mem: 436980 52576 292200 968 92204 332684
Swap: 102396 0 102396

--
64bit$ free
total used free shared buff/cache available
Mem: 429400 74000 250340 924 105060 300872
Swap: 102396 0 102396


私の持論として…
アプリケーションの整数が32bit だとしても、64bit 環境だとデータのポインタは64bitとなる。
つまり、ポインタの配列の大きなものを作ると、かなりな無駄になる。
(ちなみに、私はLispが好きなので、ポインタ中心の生活をしている。)
基本的には、実メモリが4GBytes以内の機械では、32bit 環境がいいだろうと思う。

だがっ…
ARMは 32bit と64bit では、命令が違いすぎる。
その2者の性能の違いが、私、気になりますっ。(古来の言い回し)

・演算性能

dhrystone, Whetstone などをやってみる。(どれも5回試行の平均値)















64 bit32 bit 64bit性能/32bit性能
Dhrystone
(Dhrystones per Second)
cc -I. -O4 -DREG=register -DHZ=60
3,154,043 1,887,544 1.67
Whetstone Double
(Whetstone KIPS)
cc -funsafe-math-optimizations -O4 whetd.c -o whetd-c -lm
4,505,928 3,597,883 1.25
Whetstone Single
(Whetstone KIPS)
4,202,898
cc -funsafe-math-optimizations -O4 whets.c -o whets-c -lm
3,425,286
cc -mfpu=neon-vfpv4 -funsafe-math-optimizations -O4 whets.c -lm -o whet-neon
1.23


なんとっ!!!!
64bit が、整数では 1.7倍ぐらい速いではないかっ。
これは、64bit で使わなければ…


32bit 環境でも、浮動小数点演算は64bit 演算の方が速いのが、2022年と言えようか…






Raspberry Pi 4でLisp Machine (一発芸)
※これは、 Lisp Advent Calendar 2021 のDEC/21/2021ですが、2022年正月に書いてます(^^;

Raspberry Pi 4は、64bitだし、メモリ多いし、そこそこ速いので、Lisp Machineシミュレータを動かしたい。

なんか、割と新しいものがあっさり動いて良かった。\(^^)/
(中途半端に新しいものは、Micro codeとROMの内容が合わなかったりして、難儀していた)

試した Raspi4
model: Raspberry Pi 4 Model B Rev 1.4
OS: Raspbian GNU/Linux 10 (buster)
メモリ: 8GB

ここでは、x86_64bit(amd64) Linuxも使用する。
使用した amd64 Linuxは、Ubuntu 21.04


--
今回のLisp Machine(lispm)シミュレータや、Lispm ディスク・イメージ、マイクロコードなどは、
tumbleweed.nu usim
からいただく。



まずは、amd64 Ubuntuで、下記を実行し、一式を取ってくる。

fossil コマンドが入っていない場合は、
$ sudo apt install fossil
でインストール。

$ mkdir usim-new
$ cd usim-new
$ fossil open https://tumbleweed.nu/r/l --workdir l
$ cd l
$ ./m -s

これで、自動的にmakeまで行われる。

$ cd usim
$ ./usim

で、amd64 Ubuntuで、Lisp Machine シミュレータが起動する。

遊び方は、
lispマシン・シミュレータ usim とlispマシンの使い方

usim ocumentation
を参照のこと。



amd64 Ubuntuから、Raspi4 へファイルをコピーする。

色んな方法があるが…
今回は、amd64 Ubuntuから Raspi4 へ、scpする。
対象のRaspi4 の IPアドレスが、192.168.1.19として、


$ cd ../.. (usim-new/ のあるディレクトリへ移動)
$ scp -rp usim-new 192.168.1.19:




ここから、Raspi4 で作業。
(ssh -X 192.168.1.19 とかで作業しても、特段の問題は無いはず)

Raspi4 の Homeディレクトリに、usim-new/ があるはず。


$ cd usim-new
$ cd l
$ cd chaos
$ make clean
$ make
※多少の警告が出るが、気にしない
$ cd ../usim
$ make clean
$ make

※多少の警告が出るが、気にしない
以上で、usim ができあがる。

$ ./usim

で、めでたく起動。

ただし…
Create Windowのマウス 左クリックは、すばやく3〜4回ぐらいクリックしないと、認識されない。\(^^;/
この現象は、Raspi4のコンソールでも、ssh -X でも同様。
この現象を修正したかったが、ギブアップですぅ〜

また、ssh -X は、マウスの反応にディレイがある。マウス・イベントを取りすぎているので、これは仕方ない。


なお、ディスクイメージ、マイクロコード、ROMイメージなどは、usim-new/l/sys78/ にある。

以上

これは Lispアドベント・カレンダー2020 DEC.21.2020 です。

AI言語は、LispとPrologに決まってるやろ〜 というあたくし。
Pythonって、なんや。遅いインタープリタ、ナメてんのか…

だが、Pythonって、ライブラリ呼ぶだけでイロイロできてしまう…
ライブラリの呼び出し方は、ググってコピペでOK\(^^;/

でも、やっぱり Lisp 使うぜ。
ここで軟弱な Pythonで書かれたLispを使おうかなと…

「Hy」 という軟弱 Lisp

Ubuntu 18.04.5 LTSでは、
$ sudo apt install python3-hy
で、インストールできました。

$ hy
で起動。



なんと、setq が無くて、代わりが setv。
マクロはある。
setqを defmacro するしか…
「〜」がCommon Lispの「,」にあたるようだ。



=> (defmacro setq [var val]
... `(setv ~var ~val))

=> (setq a 'asd)
=> a
'asd'
=> (setq a '(q w e))
=> a
('q' 'w' 'e')




関数でも defun するか…
あれ、defun じゃなくて、「defn」 か


=> (defn fact [x]
... (if (<= x 0) 1
... (* x (fact (- x 1)))))
=> (fact 3)
6
=> (fact 6)
720




よーし、テールリカーシブな実装になってるか、調べたろ…


=>(defn aho []
... (aho))
=> (aho)
Traceback (most recent call last):
File "/usr/lib/python3.6/code.py", line 91, in runcode
exec(code, self.locals)
File "<input>", line 1, in <module>
File "<input>", line 2, in aho
File "<input>", line 2, in aho
File "<input>", line 2, in aho
[Previous line repeated 988 more times]
RecursionError: maximum recursion depth exceeded
=>


あ、アカン、素朴すぎる… \(^^;/




fnで無名関数は作れる。
でも、クロージャは作れないようだ…アカンやん。
公式ドキュメントを「closure」でサーチしても、出てこないから、無いんだろう…


=> (setv xxxx
(do(setv lll ())
(fn [x]
(if (= x 0) (setv lll ())
(setv lll(cons lll x)) (print lll)))))

... ... ... ... => => (xxxx 0)
[]
=> (xxxx 2)
Traceback (most recent call last):
File "/usr/lib/python3.6/code.py", line 91, in runcode
exec(code, self.locals)
File ">input>", line 1, in
File ">input>", line 5, in xxxx
UnboundLocalError: local variable 'lll' referenced before assignment
=>


上は、Common Lispならば こう書くやつ (if 0は省略)

(setq xxxx
(let((lll ()))
(lambda (x)
(setq lll (cons x lll)))))

* (funcall xxxx 'q)
(Q)
* (funcall xxxx 'q)
(Q Q)
* (funcall xxxx 'q)
(Q Q Q)


hyでは、setvはバインドを行う。
doは Common Lispの prog と同等らしい。
ちなみに、バインドを起こさず、set のみ行うプリミティブは、hyには無さそうなのだが…




あと、Hy のリテラルは下の表の通り、Pythonのものと対応している。
あたくしは、Python は辞書がなければ使い物にならないと考えており…
Hy の世界でPython 辞書が扱えるのは、なかなかよろしい。
だがっ! 記号(Symbol) が無いではないか。
すべてストリングかよっ。Lispなのに記号が無い。記号処理言語なのに記号が無い…
うーん、虚しい…
多分、自分でオブジェクトを独自に作ると、GCが面倒くさくなると考えたんじゃないかな…虚しい…

この表は
https://docs.hylang.org/en/master/tutorial.html
からコピーしました。
--
Here’s an example of Hy code for each type and the Python equivalent.



HyPythonType
11int
1.21.2float
4j4jcomplex
TrueTruebool
NoneNoneNoneType
"hy"'hy'str
b"hy"b'hy'bytes
(, 1 2 3)(1, 2, 3)tuple
[1 2 3][1, 2, 3]list
#{1 2 3}{1, 2, 3}set
{1 2  3 4}{1: 2, 3: 4}dict

--


Python の関数を呼び出す。
オブジェクトは、Pythonのネイティブのままだから、Python関数呼び出しは楽でいい。

標準的なライブラリを呼び出す。

=> (import datetime)
=> (setv ttt (datetime.datetime.now))
=> ttt
datetime.datetime(2020, 12, 22, 20, 48, 31, 987827)




自作のPython関数。 "aho.py"ファイルとして下記を作る。

# aho.py
def aho1(d):
print('a')
for k in d:
print('key='+ str(k) +', value=' + str(d[k]))
## aho1({1:11, 2:22, 3:33})


そしてhy から呼び出し。

=> (import aho)
=> (setv dd {'a 'asd 'b 'qwe 'c 'zxc})
=> dd
{'a': 'asd', 'b': 'qwe', 'c': 'zxc'}
=> (.aho1 aho dd)
a
key=a, value=asd
key=b, value=qwe
key=c, value=zxc
=> (setv dd1 {'a 1111 'b 222 'c 333})
=> dd1
{'a': 1111, 'b': 222, 'c': 333}
=> (.aho1 aho dd1)
a
key=a, value=1111
key=b, value=222
key=c, value=333


まぁまぁいいね。

以上。



Tang Primer FPGA ボードが安い。
中華FPGAだが、悪くない。
RISC-V のソフトコアが入る。
ボードのドキュメント(英語)
ボードに載っているFPGA は Anlogic社の EG4S20というチップ。純粋 中華製らしい。FPGAならバックドアの心配は少ないだろう。(開発環境は、バックドアに注意する)



秋月電子などで安定して買える。
秋月 Sipeed Tang Primer FPGA Dev. ボードSwitch ScienceShige Zone
(私は、このボード1枚とJTAG 冶具は、Seeedstudio.comから 買いました)
なお、FPGAの開発を行うだけならば、JTAG 冶具は不要。

Sipeed は、中華 深セン系のチップを使用したボードをたくさん出している。そして、どれも安い。
このFPGAボードも悪いところは無い。

ここでは、Ubuntu 18.04.4 LTS での開発について述べる。




ボードを購入すると、RISC-V コアが焼かれていて、RISC-Vマイコンとして使用することもできる。
焼かれているのは、Humming bird, e-203コア。
また、FlashROMには、RISC-VでLEDを白でチカチカさせるプログラムが焼かれている。

このHumming bird, e-203コアだと、SiFive の開発環境などを、だいたい流用できる。

Humming bird core解説

RISC-V e-203 CPUのソフトウェア開発は、下記のツール・チェーン(バイナリ)をget&展開すれば、gcc, as, ld, gdb, objdumpなど使える。
RISC-V 32bit 開発環境

開発環境を展開した
sirv-e-sdk/
にて
$ make software PROGRAM=demo_gpio BOARD=sirv-e203-lichee
とすれば、
sirv-e-sdk/software/demo_gpio/
が、makeされ、RISC-V 実行バイナリが
sirv-e-sdk/software/demo_gpio/demo_gpio
としてできる。
これを、FlashROMに焼けば、Hummingbird e-203コアで実行できる。



FlashROMにRISC-Vアプリケーションを書き込むには、Sipeed JTAG(治具)ハードウェアが必要。

DigiKey
RobotShop
などで購入可能。

このJTAG治具は、FTDI 2232Hが入っているだけで、OpenOCDではフツーの構成。ST32やARMなどにも使用できるメジャー系。



e-203が入っている本ボードとの接続は表のとおり。
Tang PrimerRV Debugger
U0_RX (Pin H13) TX
U0_TX (Pin J13)RX
E_TMS (Pin C9)TMS
E_TDI (Pin B6)TDI
E_TCK (Pin C5)TCK
E_TDO (Pin A4)TDO
GND (Pin G)GND


ただし、本ボード用としてリリースされているOpenOCDそのままでは、コンパイル&リンクの終わったRISC-Vの実行バイナリをFlash ROMに書くことができない。
本ボード用としてリリースされているOpenOCDが、本ボードのFlashROMに対応していないのであった(涙)。

あたくしは、脳みそを使わず、悩んだフリをしていたが…

解決法を、教えてくれているWebページを発見した。
@Nanchite4618 さんの、
「TangPrimer(RISC-V)をArduinoIDEで開発する」というページである。

たいへん、感謝しております。

LicheeTang_openocdをダウンロード&展開し、次のパッチをあてる。
---

*** LicheeTang_openocd/src/flash/nor/spi.c.org 2020-04-04 15:53:17.000000000 +0900
--- LicheeTang_openocd/src/flash/nor/spi.c 2020-06-26 05:46:31.686017310 +0900
***************
*** 83,87 ****
--- 83,88 ----
FLASH_ID("gd gd25q16c", 0xd8, 0xc7, 0x001540c8, 0x100, 0x10000, 0x200000),
FLASH_ID("gd gd25q32c", 0xd8, 0xc7, 0x001640c8, 0x100, 0x10000, 0x400000),
FLASH_ID("gd gd25q128c", 0xd8, 0xc7, 0x001840c8, 0x100, 0x10000, 0x1000000),
+ FLASH_ID("xtx xt25f08", 0xd8, 0xc7, 0x0014400b, 0x100, 0x10000, 0x100000),
FLASH_ID(NULL, 0, 0, 0, 0, 0, 0)
};
---

その後、
$ cd LicheeTang_openocd/
$ ./configure
$ make
で、OpenOCDができる。
新しい OpenOCD一式は、
sirv-e-sdk/work/build/openocd/prefix/bin/
にコピーする。

FTDI 2232HをUbuntuに認識させるために、
/etc/udev/rules.d/45-dt2232.rules ぐらいとして
--
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", TAG+="uaccess", TAG+="udev-acl"
--

を書いて、
$ sudo service udev restart
とする。

FlashROMの焼き込みは
sirv-e-sdk/

$ make upload PROGRAM=demo_gpio BOARD=sirv-e203-lichee
する。


JTAG対応のRISC-V コアが無いと、FlashROMの書き直しができない。
万一、RISC-Vコアを消してしまった場合は、
このバイナリhttps://dl.sipeed.com/TANG/Primer/SDK/LicheeTangNewIoMap_BitStream.bit をFPGAに焼き直すべし。



FPGAであるから、論理回路を開発したい。

(※ このあたり、2023/MAR/07更新)
FPGAの開発環境は、https://dl.sipeed.com/shareURL/TANG/Premier/IDE
に行き、
TD_5.0.3_28716_NL_Linux.zip
Anlogic_20230606.lic
の2つをダウンロードする。

(昔(2020/JUNの頃)は、これだった
https://dl.sipeed.com/TANG/Primer/IDE/TD1909_linux.rar 。)

展開したあと、さきほどダウンロードした Anlogic_20230606.lic を、
TD_5.0.3_28716_NL/license/Anlogic.lic
として置く。

その後、 TD_5.0.3_28716_NL/bin/ に コマンド・サーチ・パスを通して…
$ td -gui
とやれば、GUIで開発環境が起動。

FPGAの例題は、
https://github.com/Lichee-Pi/Tang_FPGA_Examples からget

FPGA開発は、ボード上のUSBポートと Ubunu マシンをUSBケーブルでつなぐだけ。(FTDIの JTAG治具は不要)

FPGAボードをUbuntuに認識させるために、
/etc/udev/rules.d/91-anlogic-jtag.rules ぐらいとして
--
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0547", ATTRS{idProduct}=="1002", GROUP="plugdev", MODE="0660"
--

を書く。

Humming bird e-203コアの FPGA ソース
は、問題なくシンセサイズできて、FPGAに流し込んで実行できる。
RISC-Vコアはすんなりと動いて、たいへん ありがたい。


ただし、OpenOCD JTAG でFlashROMを焼くためには、下記のパッチをあてる必要あり。
--

*** Tang_E203_Mini-master/project/e203egmini_new.sdc.org 2019-07-10 19:34:04.000000000 +0900
--- Tang_E203_Mini-master/project/e203egmini_new.sdc 2020-06-27 03:34:35.549449857 +0900
***************
*** 6,12 ****
#create_clock -name CLK25MHZ -period 40 -period 40 -waveform {0 20} [get_ports {CLK25MHZ}]

create_clock -name clk_8388 -period 119.218 [get_nets {clk_8388}]
! create_clock -name clk_16M -period 62.5 [get_nets {CLKIN}]

create_generated_clock -name slowclk -source [get_nets {clk_8388}] -master_clock clk_8388 -divide_by 256 [get_nets {slowclk}]
set_false_path -from [get_clocks "clk_16M"] -to [get_clocks "slowclk"]
--- 6,13 ----
#create_clock -name CLK25MHZ -period 40 -period 40 -waveform {0 20} [get_ports {CLK25MHZ}]

create_clock -name clk_8388 -period 119.218 [get_nets {clk_8388}]
! #create_clock -name clk_16M -period 62.5 [get_nets {CLKIN}]
! create_clock -name clk_16M -period 62.5 [get_nets {clk_16M}]

create_generated_clock -name slowclk -source [get_nets {clk_8388}] -master_clock clk_8388 -divide_by 256 [get_nets {slowclk}]
set_false_path -from [get_clocks "clk_16M"] -to [get_clocks "slowclk"]
--



他のHumming bird e-20xコアの FPGA ソース



aitendo 福袋2020 の自分用メモ

・DSPラジオ 2つ


私の興味をすごく引いたのは以下


作ってもいい、と思えた基板。

ラジオばっかり。
トランジスタみたいな3端子 AM ラジオとかええかも、基板やたらデカいけど…
ESP32ボードもIchigoJam も、もうお腹一杯どす〜(^^;

ラジオ基板


マイコン基板


LCD




★特売品★Bluetoothモジュール [WML-C69] ※詳細不明なので、結局はゴミ
http://aitendo.com/product/13076





longan nano という RISC-V が載った大変安いボードを買った。

秋月で830円。(今は、メモリの少ない版しか入手できないであろう)

http://longan.sipeed.com/en/
--
メモリ:チップ内蔵128 KBフラッシュ、32 KB SRAM
汎用16ビットタイマー × 4、基本16ビットタイマー × 2、高度16ビットタイマー × 1
CPU:GD32VF103CBT6(RISC-V 32 bitコア)
ストレージの拡張:小型TFカードスロット
ディスプレイ:160 × 80 IPSディスプレイ(SPIインタフェース)

USB-Cで、PCと接続して、バイナリを書き込める。
DFUというプロトコル(?)で書く。
--





とりあえず、開発環境は、PlatformIO という甘っちょろい IDE で試用。

ホストは Ubuntu 18.04.03 LTS。( Linux 4.15.0-72-generic)

まず、VS CodeというIDEを入れ、そこに PlatformIO を入れる。
VS Codeって、Visual Studioなんだなぁ…
(Visual Studioとか大嫌い。IDEがそもそも嫌い)

PlatformIOに、longan nanoの開発ツールを入れる。
下記の通りでうまく行く。
(多少、変なことが起きた気がするが、VS Codeを再起動してやり直すと、うまく行ったり…)


https://longan.sipeed.com/en/get_started/pio.html


そして、example で、「longan-nano-blink」を開く。

ここからが、Ubuntuで DFU 書き込みのために重要。
https://bbs.sipeed.com/t/topic/1338/14 からの引き写し。


プロジェクト中の
platform.ini ファイルに
--
upload_protocol = dfu
--

という行を書く。
全体としては、
-- platform.ini
[env:sipeed-longan-nano]
platform = gd32v
framework = gd32vf103-sdk
board = sipeed-longan-nano
monitor_speed = 115200
upload_protocol = dfu
; change microcontroller
;;board_build.mcu = GD32VF103CBT6
; change MCU frequency
;;board_build.f_cpu = 108000000L
--

とした。
これで、ビルド。


DFUを使用するために、dfu-util を入れる。

$ sudo apt-get install dfu-util

そして、longan nanoの DFU デバイスを、アクセス・モード 666 にするために、
/etc/udev/rules.d/99-platformio-udev.rules として、下記を書く。
--
# Longan Nano
ATTRS{idVendor}=="28e9", ATTRS{idProduct}=="0189", MODE="0666"
--

上記を有効にするために
$ sudo service udev restart
を行う。


longan nanoを、Ubuntu に接続するときには、
1) Boot0ボタンを押下したまま、USB接続
2) Boot0を押下したままで、
3) Resetを押下し、離す
4) Boot0 ボタンを離す
以上で、アプリケーションが走行していなければOK。

DFUデバイスは、
lsusb で、表示されないこともあるが、気にしない。

以上で、Platformio から、longan nano に DFU で書き込める。



手動で、DFUデバイスを探すには、

$ sudo dfu-util -l

として、存在していればそれが表示される。

DFUデバイスのパスを知るためには、strace で、openatを捕まえる。
そして、「28e9」などをサーチすると、その直前の行にパスが見えることが多い。
(openat で、捕まらない場合もある)

# sudo strace -e trace=openat dfu-util -l
:
openat(AT_FDCWD, "/dev/bus/usb/002/016", O_RDWR) = 9
Found DFU: [28e9:0189] ver=1000, devnum=16, cfg=1, intf=0, path="2-2", alt=1, name="@Option Bytes /0x1FFFF800/01*016 g", serial="??"
Found DFU: [28e9:0189] ver=1000, devnum=16, cfg=1, intf=0, path="2-2", alt=0, name="@Internal Flash /0x08000000/512*002Kg", serial="??"
+++ exited with 0 +++


以上で、Ubuntu で、楽に使えるようになった。


だが、
書き込みする時に、いちいち、儀式と共にUSBを抜-挿しなければならないのが、大変、面倒臭い。(^^;
(これは、Windowsでも同様と思われる)


2020/JAN/03 追記

CLI(command line interface, shell)から platformio を使う方法。

・参考:

https://docs.platformio.org/en/latest/installation.html
を読んだ。


・インストール法
--
$ sudo pip install -U platformio
--

※自分用だけの場合は、上記の参考ページをよく読む。


・使用方法

プロジェクトのあるディレクトリで。
(私のプロジェクトは、 ~/Documents/PlatformIO/Projects/200102-105158-longan-nano-blink/ にあった)

## Build project
$ platformio run

## Build , platform.ini 中の envを明示指定
$ platformio run -e sipeed-longan-nano


## Upload firmware
$ platformio run --target upload

## Upload firmware, platform.ini 中の envを明示指定
$ platformio run --target upload -e sipeed-longan-nano

# Clean build files
$ platformio run --target clean

これで VS Code IEDは不要になった


これは、 Lisp SETF Advent Calendar 2018 - Qiita の DEC/21 の記事として書きました。


setcar! でググると、レンタカー屋さん と、バスなどを作ってる会社 が出てきた(^^;
なるほどっ!


純粋関数型が好きな 意識の高い人々からは、極めてバカにされている Lisp の setf などですが…
実際、副作用は良くないよね。並列化の邪魔だ。
(私は、TK80で遊び始めた頃から並列計算が好きです)

だが…
私は、setcar! (rplaca), setcdr! (rplacd) を使う。断じて使う。
(私はCommon Lispを書くことが多いので、rplaca/rplacd/setf を使う)


Lispで、プログラミング言語の実行系をつくるのは、誰もが、しばしば(バシバシと)行っているであろう。

・いにしえの素朴なLisp インタープリタを作るとき…
変数などのバインディング状況を環境として作り、その環境をリストでつないでいくであろう。

バインディングの表現方法によるが、変数の内容が更新された時、setcdr! (か、setcar!) を使うことになるであろう。
実現方法が素朴であり、それなりの実行速度を求め、かつ、プログラマが楽をしたければ。(^^;

また、関数呼び出しから戻るとき、
(C言語的な表現ならば、スタックを巻き戻すとき)
環境リストの新しいものを切り捨てて、古い方の環境を最新にする。
これも、環境リストの表現方法によるが…
環境リストの最新を保持する cons の carかcdr を set! する(つまり、setcar! か setcdr!する)
ことになるであろう。(環境リストを単純な変数で保持していたら、その変数にset!するだけだが)
大域脱出などで、環境リストを、いきなりたくさん縮めたいときに、setcdr! したい気持ちが高まる(であろう、たぶん…きっと…)。



・Prologインタープリタを Lispで作るとき…

Prologの変数は、双方向代入であり…
ず〜っとアンバウンド(未代入)の変数の値が、どんどん呼びだされた後の節の中で決まり(バインドされ)、
それが呼び出し側(環境リストでいうと浅い側の環境の中)の変数に反映されなければならない。
これは、もう、環境リスト中の変数の値を、set!(インタープリタの中では、setcdr!ぐらい)を、行うしかないっ!
(凡人の脳では)

そして加えて…
Prologが素晴らしいのは、バックトラックが行われた場合、
上記のような変数のバインディングは、キレイさっぱりと、忘れてしまわなければならないことである。
その実現を、素朴な凡人脳でプログラムすると、
環境リストの途中を setcdr! して、
忘れてしまいたいバインディングを保持した環境を、切り離してしまうことであろう。

うほほ〜い、setcar!/setcdr! 最高〜\(^^)/


・Schemeの setcar!/setcdr! が rplaca/rplacd でないのは…
私は、
「SchemeにMAC Lisp上に書かれていたものがあって、関数名がMAC Lispとぶつからないようにしてたのじゃないかな〜」
と、勝手に想像してます。



・ちなみに、Common Lisp の setfは、私の中では…
- 値を得る直前に、寸止めして、参照場所を見るだけとして堪え、
- そこに値をぶち込む
という行為に、
マゾ感覚(寸止めで我慢) と、
サド感覚(最後に、値をぶち込む)
の両者を感じ、大変に感情を揺さぶられる 魅惑的な機能として位置づけられている。
また、setfは、純粋関数に反した背徳的な行為であることも、その魅力を、指数関数的に増大させている。


もう、私は、setf/rplaca/rplacd 無しでは、退屈すぎて、クリスマスも自宅で寝るしかないのである。
(setf/rplaca/rplacd があっても、クリスマスは自宅で寝ると思われるが…)

これは、関西Lisp アドベント・カレンダの 2017年12月2日です。

 

  • 基本Lisp小咄

    Lisperには紅茶好きが多い(?)

    LisperA: 「foodp ?」(和訳: 飯に行かない? ) 
    LisperB: 「T」(yes) 
    飯屋に行き、一通り飯を食い終わったところにウエイトレスが来て、
    ウエイトレス: 「Coffee?」(コーヒーはいかが?)
    Lispers: 「T」
    少し後、紅茶(ティー)が運ばれてきた…

 

  • どうして CAR は、左の要素を取るのか
         「クルマ(Car)は左」というじゃろ。
                 ただし、日本とイギリス限定 (^^;
                 (このネタは、竹内郁雄さんの文章で読みました)
 
  • 「ラムダ文字山」
 

a>

 
  • 火星のラムダ文字山
 

 
お粗末
 

 
 
 

関西Lisp のネタのために、usim を引っ張り出してきた。

古いオリジナルのものをそのままmakeしても、動作した。(64bit Linux用に、ちょっと直した)

 

g000001さんのusimの記事"http://g000001.cddddr.org/3700105594"にある 

この GitHub: ams/mit-cadr から、 download Zip で得たものも簡単に動いた。

 

OSは、Ubuntu 16.04LTS 64bit。

 

usimは、32bit で make して吉。

 

ubuntu x86_64 の場合、32bit コンパイル環境を入れる
 $ sudo apt-get install libc6-dev-i386
 $ sudo apt-get install libsdl1.2debian:i386

そして、Makefile をちょっと変更。

 

--------

*** Makefile.org    2017-04-02 17:15:10.000000000 +0900
--- Makefile    2017-10-09 22:00:15.842199400 +0900
***************
*** 34,41 ****
  endif
  
  ifeq ($(OS_NAME), Linux)
! DISPLAY = X11
! KEYBOARD = OLD
  endif
  
  #----------- code ------------
--- 34,43 ----
  endif
  
  ifeq ($(OS_NAME), Linux)
! #DISPLAY = X11
! DISPLAY = SDL
! #KEYBOARD = OLD
! KEYBOARD = NEW
  endif
  
  #----------- code ------------
***************
*** 77,83 ****
  ifeq ($(DISPLAY), X11)
  LFLAGS = -m32
  ifeq ($(OS), LINUX)
! USIM_LIBS = -L/usr/lib/x86_64-linux-gnu -lX11 -lpthread
  else
  USIM_LIBS = -L/usr/X11R6/lib -lX11 -lpthread
  endif
--- 79,86 ----
  ifeq ($(DISPLAY), X11)
  LFLAGS = -m32
  ifeq ($(OS), LINUX)
! #USIM_LIBS = -L/usr/lib/x86_64-linux-gnu -lX11 -lpthread
! USIM_LIBS =
  else
  USIM_LIBS = -L/usr/X11R6/lib -lX11 -lpthread
  endif
***************
*** 90,97 ****
  #CFLAGS= -O3 -march=pentium3 -mfpmath=sse -mmmx -msse $(DEFINES) -Walle
  #CFLAGS = -O3 -fomit-frame-pointer -mcpu=i686 -g $(DEFINES)
  #CFLAGS= -O3 -mfpmath=sse -mmmx -msse $(DEFINES) -Walle
! CFLAGS = -mfpmath=sse -mmmx -msse -DMAP_SITE_TREE_DIRECTORY $(DEFINES) -g
! LFLAGS = -ldl -L/usr/lib
  USIM_SRC += Files.c glob.c
  USIM_HDR += Files.h glob.h
  USIM_LIBS += -lrt
--- 93,103 ----
  #CFLAGS= -O3 -march=pentium3 -mfpmath=sse -mmmx -msse $(DEFINES) -Walle
  #CFLAGS = -O3 -fomit-frame-pointer -mcpu=i686 -g $(DEFINES)
  #CFLAGS= -O3 -mfpmath=sse -mmmx -msse $(DEFINES) -Walle
! #CFLAGS = -mfpmath=sse -mmmx -msse -DMAP_SITE_TREE_DIRECTORY $(DEFINES) -g
! #CFLAGS = -mfpmath=sse -mmmx -msse -DMAP_SITE_TREE_DIRECTORY $(DEFINES) $(M32) -g
! CFLAGS = -O4 -mfpmath=sse -mmmx -msse -DMAP_SITE_TREE_DIRECTORY $(DEFINES) $(M32)
! #LFLAGS = -ldl -L/usr/lib
! LFLAGS = $(M32) -ldl -L/usr/lib
  USIM_SRC += Files.c glob.c
  USIM_HDR += Files.h glob.h
  USIM_LIBS += -lrt
***************
*** 110,116 ****
  M32 = -m32
  
  ifeq ($(DISPLAY), SDL)
! USIM_LIBS = /usr/lib/libSDL-1.2.so.0.7.0 -lpthread
  endif
  
  endif
--- 116,123 ----
  M32 = -m32
  
  ifeq ($(DISPLAY), SDL)
! #USIM_LIBS = /usr/lib/libSDL-1.2.so.0.7.0 -lpthread
! USIM_LIBS = /usr/lib/i386-linux-gnu/libSDL-1.2.so.0 -lpthread
  endif
  
  endif

---------------------------------------

そしてmake すれば、OK。

 

$ ./usim で、起動する。

 

 

 

<hr>

 

XBee をだいぶ前に、入手して、少し遊んでいた。

だが、End Device APIだか、End Device AnalogIOだったか、ADC を読み込んで、自動的に送出する ファームウェア を焼いたら、ちっとも通信できなくなった… orz

 

そして、ファームウェアの更新(元に戻す)も、できなくなった…

 

急に思い立って、真面目にググって見つけたのが…

「Bootloader to force XBee reflash」

http://www.digi.com/wiki/developer/index.php/Bootloader_to_force_XBee_reflash

 

これでうまく、ファームウェアを焼き直せた。

 

僕の XBee は、XB24-Z7CIT-007 

 

要するに…

DTR (9ピン), DIN(3ピン) を GND に落として、reset する。

僕の場合、それで、Bootloader が起動した。

シリアル端末を、115200bps, 8bit, non-parity で、つないでおけば、boot loaderの起動メッセージが見えて、判る。

 

その後、X-CTU を起動して、強制的にファームウェア更新を行えば、良し。

 

 

「Bootloader to force XBee reflash」の内容、正確には…

DTR (9ピン), DIN(3ピン) を GND に落として、reset する。

シリアル端末を、115200bps, 8bit, non-parity で、つないで、

"B", 「CR」

を打ち込むと、boot loader が起動すると、書いてある。

 

 

ま、とりあえず、ATコマンドで遊べるように戻ったので、めでたい。