アップグレードの話ではなくてね... 昔、といっても 22 年ちょっと前ぐらいの話だが、Omoikane GNU/Linux から触りだした Debian GNU/Linux で、最初の頃はよく自分でカーネルビルドをやっていた。 NVIDIA の XFree86 driver の関係だったか、そのほかの理由だったかは忘れてしまったが、まだ initramfs もなくて、initrd も使っていたかどうか、みたいな頃だし。 あの頃は Debian GNU/Linux 2.2 の本の解説を参考に、linux-source-バージョン、というパッケージを入れて、.config の設定などを済ませて、make-kpkg というコマンドでカーネルパッケージをビルドしていた。 2004 年に何かやっているのは大学の研究室のノートパソコンの話で、やはり make-kpkg コマンドを使っている。
で... そのあたりからだんだんとカーネルビルドする機会も減っていって、いやまぁ仕事ですることは時々あるんだけど、ちょっと試すだけのためにわざわざパッケージ作らなくてもいいや、ということで、make-kpkg コマンドを使わなくなって早 10 年 (本当か?)、みたいな。 とにかく、コマンド名すら忘れていたことに気づいて自分で笑ってしまった。 頭の中で dpkg-buildpackage とごっちゃになっていた。 カーネルパッケージだよなー、でもマニュアルを検索しても出てこないし、パッケージを検索しても出てこないし、何てコマンドだったかなー、というところで、トイレに行ったときにふと、make-kpkg という名前が頭によみがえってきて、検索したら、なんとこのコマンド、消滅していた。 そっかー! 過去の話だったかー!
今は、カーネルソースの Makefile のどこかに書かれている、deb-pkg あるいは bindeb-pkg というターゲットを使うらしい。
一度見たらいろいろ思い出して、fakeroot make-kpkg --initrd kernel_image みたいな感じで使っていたな、となったけど、もうこれは忘れていていいのね。
Basic Pascal Tutorial/Contents - Free Pascal wiki
Pascal のチュートリアルだ。 Free Pascal という Pascal コンパイラーのサイトだけあって、うさんくさい資料よりは整っている感じがする。 とはいってもあまり詳しい説明はない。 まぁチュートリアルだしな。
program FizzBuzz;
var i : 1..4294967294;
begin
for i := 1 to 4294967294 do
begin
if i mod 15 = 0 then writeln ('FizzBuzz')
else if i mod 5 = 0 then writeln ('Buzz')
else if i mod 3 = 0 then writeln ('Fizz')
else writeln (i);
end;
end.
FizzBuzz を書いてみた。 遅いけど、ちゃんと動く。 Pascal ってほとんど触ったことがないけど、subrange って型はおもしろい。 あの高速化の話を試すにはまだ Pascal の知識がなさすぎる。
曇り時々雨。 涼しい日。
テレビでやってた映画『スパイダーマン: ノー・ウェイ・ホーム』(原題: Spider-Man: No Way Home)。 2021 年のアメリカ映画。 日本公開は 2022 年。 何この漫画みたいな展開... あっ、原作はアメリカンコミックだから漫画かw 懐かしのスパイダーマン (21 世紀の映画版) の主役が他にふたりも出てきたよw 敵にも懐かしい顔がいるしな。 Tingle を信じろ! 記憶操作の魔法。
晴れるのかと思ったらずっと曇っていた。 チラッと雨がぱらついた時もあった。 寒い日。
図書館に行って、古い朝日新聞を検索した。 1999 年までの記事は、ちゃんと全国版の地域面まで検索できる。 それより後のことはよくわからない。 鹿児島の地域面はだいたい 1 面から 2 面だったようである。 出身中学でリアルにあった暴力沙汰のニュースがどっかにあるかと思ったが、見つからなかった。 鹿児島の図書館で南日本新聞を検索した時にも出てこなかったしな。 謎だ。 なお、田舎の祖父母の家の町にあった県立高校が廃校の危機という記事はあった。 その記事から 9 年後に閉校したんだな。
テレビアニメ『呪術廻戦』。 40 話。 渋谷。 渋谷の大変な現場にいる先生の喫煙シーン。 細かいいざこざの後は特級バトル。 呪霊と、主人公を乗っ取っている呪霊と、特級同士でも格が違う。
テレビアニメ『葬送のフリーレン』。 10 話。 フリーレンの過去、魔法使いの先生との話の振り返り。 今回はいろんな魔法使いによくオーラが出てくる。 魔力が魔族の階級、そして魔王。 魔力をごまかして魔族を欺いて勝つ!
テレビアニメ『オーバーテイク!』。 6 話。 鈴鹿。 検索エンジン "Mauchly BETA"。 雨。 濡れた路面と乾いた路面の表現は苦労していそうだな。 現実のレース中継の映像のほうがその境目はわかりやすく映し出される。 そしてスリックタイヤで雨はあっという間にレインタイヤに抜かれると思うけど?w 主人公のライバルが、追突スピンからの T ボーンクラッシュ。 これはね... まぁたまにあるんだよねそういうの... 2019 年の F2 の死亡事故もスピンした車両に横から突っ込んでいたからね... 自分なんかが出るようなアマチュアカートレースはスピードが遅いのでそこまでひどいことにはならないけど、たまーに横転事故はある。
Lazarus という Free Pascal の統合開発環境があって、ちょっと触ってみた。
apt install lazarus で入るんだが何かが足りないらしく、apt install fp-units\* で押し通した。
さてこれ、往年の Visual Basic を思い出すようなできばえだ。 使い込むとどうなるのかわからないが、少なくとも取っつきやすさの点ではすばらしいものがある。 立ち上げたら最初っから Form1 が出てくる。 メニューを適当に漁ると [表示] メニューに [コンポーネント] というのがある。 それを押すと button とか label とかいかにもなコンポーネントが並んでいる。 適当に button をダブルクリックするか、または、シングルクリックしてから Form1 の中でクリックすると button が配置される。 [実行] メニューの [実行] を選んだら、名前を付けて保存すらしていないそれがコンパイルされて起動する。 うわぁ、簡単!
当然、配置した button をダブルクリックすれば procedure TForm1.Button1Click などとソースコードに書き加えられてソースコードエディターに切り替わる。
素の Pascal すらよくわからん自分にはオブジェクト指向 Pascal のことなどさっぱりだが、試行錯誤してみると、Form1.Label1.Caption := 'hoge'; という書き方で label の変更に成功した。
コード中には var のところに Form1: TForm1; と最初から入っていて、その下に勝手に foo : integer; を書き加えて、Form1.Label1.Caption := inttostr(foo); とかえたらちゃんと数字が出るようになった。
(inttostr については web 検索して調べた。)
foo := foo + 1; も書き加えれば button をクリックするたびに数字が増えていく。
ほぉー、簡単!
Delphi の経験があるならさらにすいすいいけるんだと思うが、この手のパソコン用 GUI 開発環境は Visual Basic しかまともに触っていない自分でも、おおかた想像が付く範囲でぺこぺこ触れるのは楽しい。 しかもこれでクロスプラットフォームなんでしょう? すごいんじゃない?
といいつつ 7 年前には Qt Creator っていうのを触ってみたこともあった。 あれはあれで悪くはなかったが、C++ なのでプロパティがなくて、いちいちメソッドを使うのが、元 Visual Basic 愛用者としてはやや面倒くさい感じがしたっけ。 Windows なら Visual Studio で C# あるいは Visual Basic (.NET) という選択肢もありだが、マルチプラットフォームとなると Mono で実行はできても、統合開発環境としては、MonoDevelop は開発終了したみたいだし、Windows しかないんじゃないかな。 あとは Eclipse で Java でみたいなのはあるんだろうけどね。 Lazarus は、かつて Delphi が盛り上げた Pascal の発展版の言語で、競合が少ないので人気が分散せず、地道に開発が続いて生き残っている珍しいパターンだろう。
今時のはやりの言語といったら Go や Rust なんかがあるんだけど、それらの GUI フレームワークはあまり定番ものがないらしい。 Go は自分がほとんど触ったことがないせいもあるが、なんだかんだ乱立していてよくわからんという感じがある。 そんな状況だから今はまだ統合開発環境でポチポチやってできるような世界じゃない。
なお、プログラミング言語のプロパティというのはいつからあったのか、調べてみたんだけどわからないw Object Pascal かと思ったけど Delphi でプロパティが導入されたよって説もあり、それならば少なくとも Visual Basic のほうが早いことになる。 でも 1990 年代の Visual Basic は厳密なオブジェクト指向とはちょっと違っていて、オブジェクト指向っぽい概念が多く取り入れられた言語だった。 あるいは Smalltalk にあったというプロパティが由来なのかも知れない。
30 個ずつまとめただけでまだ高速版とは言い難いが、一応 120MiB/s ぐらいが出るバージョン。 改行コードを LF 限定で書いてあるため Unix 環境でしか正しく動作しないだろう。
strace で見ると 256 バイトずつの write になっている。 内部のバッファーが小さいんだな。 それを増やすことができればそれだけでもだいぶ性能あがりそうだけど、今は数値から文字列への変換も標準的なものなのでそんなにはいかないと思う。
Basic は久しく触っていないので忘れかけているものの、Pascal を触ると何か思い出してくるものがある。 QuickBASIC や Visual Basic と比較して、以下のような共通点がある:
昔の (QuickBASIC より前の) BASIC と比較して、以下のような共通点がある:
Pascal コードを書いてみて躓くのは、慣れない := と ; の独特な使われ方だが、:= はともかく、; は昔の BASIC の IF 文を思い出すと納得できなくもない。
IF A THEN B ELSE C スタイルなのは基本的に Pascal も同じで、複数の文を入れる場合は、BASIC でいう : の代わりに begin 〜 end を使って、その中で ; を使っていくが、; は IF 文全体の最後につく感じ、すなわち BASIC で言う行末にあたる部分に ; を入れる。
ちなみに end の直前は ; を入れても入れなくても良いが、ソースコードの編集のしやすさと、バージョン管理システムの diff のことを考えれば、入れるほうが後々便利だろう。
for なんかは do もあるのでどっちかというと MS-DOS の COMMAND.COM にある FOR を思い出す感じかな、あれは複数コマンドを書くことができなかったが、あれの行末にあたる部分に ; を入れて、複数行書きたければ begin 〜 end を使う感じで。
文字列型に関しては C の NUL 終端と違い、長さに上限ができるものの、NUL 文字を含むことができるのと、NUL 探索の必要がないのでパフォーマンス面では有利なはず。
strcat や、printf の %s にしたって、あるいは puts にしたって、NUL を探索しなくても長さがわかりきっているなら、いきなりメモリーコピーを始めることができる。
実際、上のプログラムで使った Pascal の write 文は、文字列のアドレスを順に渡していくような機械語になっていて、それが NUL 探索をしないのはだいぶ有利だろうとは思う。
まぁ、それ以外が全然効率良くないのでアレなんだけどw
Free Pascal がはき出したバイナリを逆アセンブルすると結構ね、DOS 時代の高級言語のプログラムを思い出すような、なんでこんな無駄なことやってんの!? みたいなね...
Free Pascal は LLVM 対応も進めているようなので、将来的には LLVM 対応アーキテクチャーではだいぶマシなコードが生成されるようになるんだろうけどね。
曇り。 たまにパラッと雨。 寒い日。
テレビアニメ『16bit センセーション ANOTHER LAYER』。 6 話。 コンシューマー移植の続き。 監視役。 「エロゲー」が「美少女ゲーム」へ。 たまごっちの流行が終わっていた、それはそう、1999 だろ? AIBO かぁ、そういうのもあったね。 そして事件。 「節電」、あの頃からあったかな? 熱い主人公。
このアニメのエンディングに出てくる PC-98, RA か DA か、フロッピーディスクドライブのアクセスランプと、電源ランプの横のアクセスランプが同時に点滅するのがなんか違和感があるんだけど、それは電源ランプの横はハードドライブのアクセスランプだったんじゃないかと思うからだ。 実家で使っていた 9801RA2 はハードドライブは外付けだったのでそのランプは光っていなかったはず... でも実際光ってもおかしくないような気もしてきた。 PC-98 のフロッピーディスクドライブのアクセスランプは、IBM と違って、データ転送中のみ光るようになっていた。 (IBM は JX を含めドライブ選択・モーターオンの時に光る仕掛け。) で、ハードドライブのほうはよく知らないんだけど、IDE とか SASI とか、そのへんの仕様で、フロッピーディスクドライブと同じ内蔵の 8 ビット DMA を使ってデータ転送をしていたはずだ... なのでもし DMA とアクセスランプがつながっているのなら...
いや待って、それだと DMA 使わないで転送したら光らないことになるからおかしいな。 検索するとマザーボードから HDD のアクセスランプの信号線がきていたらしい情報があった。 やはりハードドライブ用か。
ウォーキングは歩幅を広くするのを意識するとだいぶ足の負荷があがるような感じがする。 ダイエット的にはそのほうがいいかも。 座骨神経痛的にはいいのか悪いのかよくわからないので様子を見るしかない。 今日は大丈夫だった。
バッファーサイズの設定の仕方がわかり、少し高速化した。
1 分 40 秒ぐらい。
C とアセンブリ言語でいろいろやった経緯から言えば、まだまだできることは多いんだけど、文字列の一部を書き換える (move?) のがいいのかな、さすがに型を無視して 8 バイトを一回で書き込むのは無理かな、あるいは packed でいけるのかな? などと、Pascal の知識がないのでいろいろ想像が膨らむ。
Pascal の配列の表現、var buf : array[1..8192] of byte; っていうのも、Visual Basic の Dim buf(1 To 8192) As Byte にも引き継がれている感じがちょっとある。
ただ、この Pascal の 1..8192 は、なんと型らしい。
例の subrange だ。
なので、enumeration もそのまま配列の添え字に使えるっていうことだ:
type hoge = (foo, bar, poi);
var hogedata : array[hoge] of integer;
このへんは今見てもおもしろい言語だな。
晴れ。 寒い日。
寒いのでずっとエアコンつけていたらだいぶ乾燥していた。 が、まぁ、まだ 30% こえているからマシなほうだ。 冬になったらもっと乾燥するからなぁ。
インターネット (笑) では時々、田舎は都会より生活費が安いのか論争が繰り広げられる (笑)。 毎回決まって、どんな田舎が想定されているのか書かれていないから、話がかみ合わない (笑)。 例えば、ここ東京競馬場がある府中市だって、中央道のすぐそばに田んぼがあったり、コイン精米所があったりするので、ちょっとした田舎のようでもあるし、実際、昔は田舎と言ってもおかしくないようなところだったんだろうと思われる。 宿場町だけどね。
まぁ、それはともかく、自分の感覚的には、子供の頃に長く住んでいた鹿児島市は田舎とは言えない。 近所に田んぼなんてなかったし (笑)。 生まれたところの国分市はまぁ、田舎かなー。 今は霧島市、年に数回帰省した時に見るだけだけど、あのあたりは生活費は安そうではある。 それは、家賃が安そうなのと、地元産の食べ物が安いっていう... 例えば、鹿児島だと鹿児島県産の黒豚は関東より遙かに安い、みたいなのはある。 九州は鶏を出荷しているところも多いから、それも安いと思う。 野菜はそんなに変わらないかな。 ガソリンは安くはなさそう。 飲食店が安いのは人件費の関係か。 総菜も安いんじゃないかな。
でもまぁ、そんな田舎の感覚ってわからんよな、住んだことはないし、と思っていたが、冷静に考えたら、茨城県に住んでいた時のあのあたりは田舎だった。 5 分ちょっと歩けば田んぼが見えてくるところに、7 年も住んだじゃないか (笑)。 まぁ生活費は安かったね。 東京郊外の 1K の家賃ぐらいで、茨城なら一戸建てがある、みたいな、そんな世界だったし、ドラッグストアで買う牛乳なんかも安かった。 牛乳も、栃木県とか群馬県とか、北関東で間に合っているというかね、やっぱり近いのは有利なんだよな。 学生向けっぽい弁当屋さんも、キャベツたっぷり弁当 210 円、みそ汁無料、みたいなのは、さすがに安いよね。 コンビニはどこもほとんど同じだけど。 もしカワチ薬品にもカスミにも行かずにコンビニで済ませる生活をしていたなら、東京と変わらなかっただろう。
ホンダ 400X の後継? に NX400 というのが話に出ている。 が、これが 270 度クランクらしい。 つまり NC750X みたいなドコドコするやつだ。 NC750X に 1 年ちょっと乗った結果、個人的には振動は小さなほうが好きだ。 つまり 400X を買っておいて正解だなw
ま、それはいいとして、なんとハーレーダビッドソンが X350 という普通二輪クラスの新型車を出したらしい。 ハーレーダビッドソンといえば V 型エンジンだが、この X350 と、ひとまわり大きな大型二輪の X500 という新型車は、直列二気筒エンジンを採用しているとのこと。 で、クランク角はなんと 360 度とのことだ! 直列二気筒で 360 度ってことはピストンの上下の動きによる振動が打ち消されないわけで、採用車種は少ない。 そんな珍しいエンジンと、ちょっと車重が重いのが、他との差別化だろうか。 スクリーンもない、カウルもない、0.35 L クラスのバイクで、195 kg というのは正直重い。 でも重いほうが横風に流されにくく長距離は楽になるからね、そのへん、小さくなってもハーレーダビッドソンらしいところなのかも知れない。
バイクで振動が少ないって言ったらバンク角 90 度の V 型二気筒エンジンだ。 二気筒でクランクを共有するので横置きであれば横幅が狭く、しかもバランサーがなくても振動が小さいらしい。 V 型エンジン車で公道で乗ったことがあるバイクはヤマハ ドラッグスター 250 だけ、バンク角は 60 度だそうで、特に振動が小さいとは思わなかった。 国産の現行車種で言うとスズキの SV650 やら V ストローム 650 やらが 90 度の V 型エンジン搭載車。 もっと大排気量のものもあるけど、普通二輪クラスのほうは消滅している。 SV650 はスクリーン・カウルがないものの、199 kg で親しみが持てる (?) 車重だが、まぁ、そう、V 型エンジンはカムシャフトが別々に必要になるぶん重量で不利だし、0.65 L の排気量も当然不利なのに、ハーレーの X350 がこれより 4 kg しか軽くないのはちょっとね...
晴れ。 朝の冷え込み方がすごかった。 頻尿もすごかった。 夜は散歩しに外に出た感じではきのうほどではなかったと思う。
Pascal。
SwapEndian という関数でバイトスワップできるらしい。
あと byte の array に型をつけておいて、その型名を関数名みたいにして使うとキャストになるのかな、その手で 64 ビット値を 8 ビットずつアクセスできるようにする手があるようだ。
あるいは move って procedure を使えば 64 ビット値をそのまま文字列の一部にコピーすることもできる。
意外と C みたいなこともできる言語なんだよな。
ポインターとキャストでごちゃごちゃするのもできるのかも知れないけど、そこはよくわからない。
テレビアニメ『MF ゴースト』。 6 話。 Takumi Fujiwara は悲運のラリーストなの?w そんな設定なのか。 リアエンジンのブレーキの話。 オーバーテイクが決まっていく。 なんでストレートでリアウィング立てるんだ? 逆じゃね? コーナリングで抜き、パワーの差で抜かれ。 レースは 2 周目がある。 はてさて。
テレビアニメ『るろうに剣心 ―明治剣客浪漫譚―』2023 年版。 19 話。 けんか屋と昔の仲間。 の、けんか。 解決して、その後。
テレビドラマ『トクメイ! 警視庁特別会計係』。 5 話。 コンピューターウイルス? ランサムウェア。 管理官。 小鳥ちゃんだった過去。 名物もやしカレー。 管理官に部屋を取られた副署長。 「ばか」を連呼するキャリア (笑)。 「Chat Pipo」「チャットピーポー (仮)」。 問題解決!
46 秒ぐらい。 write に渡すのを細切れの文字列じゃなくてまとまった文字列にして、move で途中の数字を書き換えていく版。 やはり細切れのデータをバッファーにコピーしていくのは効率が悪いんだろう。 writev システムコールで全然速くならなかったのと同じような感じ?
んでこれもまだまだチューニングの余地がある。
packed というキーワードを使えば、C で書いた時みたいな構造体を作ることができそう。
でも文字列じゃないと write できないのでは、というところだが、同じバイト数の char の配列の型を別途宣言しておいて、それにキャストをすれば、write できてしまうみたいだ。
つまりポインターをこねくり回さなくても、move も使わなくても、普通に 64 ビットで値を代入していって write に渡すというのはできる。
C++ で書いたやつみたいにきれいに書くのは難しそうだが、SwapEndian もあるし、同じ作戦で高速化の見込みがある。
バッファリングの解除ができないのかも知れないが、それでもそこそこのところまではいけるんじゃないか。
晴れ。 寒い日。
TIME DISH っていうレトルトおかずのサムゲタンってのを食べてみたらなかなか美味かった。 朝鮮料理なんだろうけどキムチみたいな辛いやつじゃない。 まぁ、その TIME DISH ってのは割とお高くて、スーパーで買ったときにたまたま賞味期限が近くて半額だったから割安な感じだが、値引き前は 400 円超の値段がついていた。 湯煎だけでなく、袋ごと電子レンジ調理も OK で、肉も野菜もとれる便利なやつだから、そんなもんなのかも知れない。 量も少ないんだけど、夜は少なめでいいかな、っていう...
実は、文字列の一部を qword で書き換える超邪道っぽい方法も発見はしていた:
qword ((@z[2])^) := qword (100);
こんな感じで強引に書き込むことはできるらしく、これは C で言うところの *(uint64_t *)&z[2] = 100; みたいなものと言えよう。
ポインターを介すことで、長さが吹っ飛んでしまってキャストができるらしい。
まぁしかし、アドレスオペレーター @ というのは Borland の拡張とのことで、標準仕様にはないんだね!
ほー!
というわけで、作った上のプログラムだが、これは packed を使っているので、これもまた何かの拡張であろう。
と調べると packed は ISO 7185 に定義されているらしい?
へぇ?
まぁいいや。
こんな趣味の遊び、動けばいいんだよ、動けば!
これで実行時間は 17 秒ぐらいだ。
先月の 30 ずつ書く C バージョンと同等、なかなかいい線だな。
逆アセンブルするとだいぶ call がたくさん出ている感じがするが (小さな関数もインライン展開はされていなくて、バイトスワップでさえも call になっている)、メモリーに埋めていく部分は期待通りの mov の羅列。
今時のプロセッサの分岐予測がきけばこんなものなんだな。
まぁ、後は Pascal の write と libc の fwrite の差というかね。
SwapEndian よりも、やりたいことを表している NtoBE を使ったが、他のアーキテクチャーでまともに動かなくてもびっくりはしないし、そもそも x86 でもオペレーティングシステムによっては改行コードで躓くという話もある。
16 進数定数の表記がプリフィックスで $ というのはあまり予想していなかった。
8 進数は & で、2 進数は % だそうだ。
なんかこう、もうちょっと拡張性のある手法はとれなかったのかね?
C の 0x にしても、BASIC の &H &O にしても、将来増やす余地もありなかなかわかりやすい表記だと思うんだけど。
(C の 0 をつけたら 8 進数というのがわかりにくいことについては見ないふりをする。)
晴れ。 そんなに寒くなかった。 明日の午前中は荒天の予報だ。
NTT ドコモの携帯電話回線、都心であまりにつながらないのを最近は改善しつつあるという話が報道されていたが、実際のところ結構つながらないみたいで、他社に乗り換えたとか、乗り換えたいとか、そういう話を耳にしつつある。 空港でつながらないとか、駅でつながらないとか、昔のムーバっていう第二世代携帯電話の頃や、ごく初期の FOMA っていう第三世代携帯電話の頃にはそういう話もあったけど、2023 年にもなって聞くことになるとはね! おそらく問題になっているのは都心だけなんだろうが、とはいえつながらないのは困るよな。
Y!mobile の PHS から移行してもう 3 年経った。 PHS と比較して特にエリアが狭いという印象はないし、通信スピードも気にならない。 PHS が最後までエリア外だった祖父母の家でも使える (笑)。 渋谷のような街中、空港や港でつながらないという状況にも今のところ遭遇していない。 音声通話は音質は良い。 PHS 同士に比べると、背景の雑音が消されるのと、やや遅延が大きい感じがするものの、そのへんはどうしようもないか。 第三世代携帯電話のこもったような音を思えば、比べものにならないほど良くなった。 時々変な繰り返しみたいな音になる現象は、前の Android One S6 に比べて今の Android One S9 のほうが遙かに頻度が低くなったので、たぶん端末のせい。 過疎地のエリアはたぶん povo に負けているんだろうと思うが、それはフェリーに乗った時の経験や、高速道路でインターネットラジオが切れてしまった経験による。
歩幅を広くしてせっせと進むウォーキングでも、Google Fit の計測によれば、1 km あたり 12 分から 13 分かかっている。 ...なんだ、この表記? まぁつまり、時速 5 km は出ていないということだ。 自分的にはかなりがんばったなーという速さなんだけど、そんなもんか。 駅徒歩何分の情報は時速 4.8 km だそうで、自分的にはかなりがんばらないとクリアできない。 Google Maps のルート検索で試してみると徒歩は時速 4.3 km ほど。 それぐらいならいけるな。
11.8 秒ぐらいまで来た。 前に C++ でやったのと基本的には同じ、バッファーサイズを決めてそこまでがんがん埋めて、まとめて書く。
っていう話なんだけどまずはバッファリングをどうやってやめるのか。
バッファーより大きなサイズを write しても毎回同じアドレスが write システムコールに渡されていたからそれはメモリーコピーが走っているということで、他の方法が必要だ。
Pascal にはテキストファイルを扱う text とバイナリファイルを扱う file っていうのがあって、バイナリのほうにはバッファリングがないようだ。
しかし標準出力である output は text であり、バイナリを出力するにはどうすればいいか?
というと、なんと assign にファイル名として '' を指定すると標準出力 (標準入力も?) が選択できるらしい。
ということで file で標準出力が扱えることがわかった。
次に file に書き込む方法だが、write でもいいんだけど write には長さが指定できず、file of 何々で指定した型の書き込みとなるらしい。
それは面倒だなと思って探していたら、blockwrite というのが出てきた。
これは fwrite みたいに、ある長さに指定の回数をかけた内容を書き込むもので、file に of を指定しなかったら 128 バイトになっていたっぽいな。
なので of char にして、バイト数を指定することにした。
あとは適当に packed record を配列にして書くだけだ。
手抜きで 1000000 以降しか高速化していないけど、十分いい感じになっている。
と思いながら最初書いたコードを逆アセンブルしたら笑った。
rec[i]. を何度も並べていたところ、アドレス計算が毎回毎回かけ算になっていたw
with にしたらそれは解消したようだ。
そのへんに現状の Free Pascal コンパイラーの、おそらく LLVM 化すると解消するであろう弱さが見える。
なお、毎回同じ数のかけ算をしていても 12 秒を切っていたんだから CPU のことはよくわからないw
調べていたときに fpwrite というのも見つけていた。
これはより直接的に write システムコールにつながる、Unix 用のユニットにあるらしい。
雨のち曇り。 出社した。 朝はもうちょっと雨がやむ瞬間があるかと思ったんだけどな、ずっとしょぼしょぼ降っていた。 一番ひどかったのは正午頃だけど。
テレビでやってた映画『ミラベルと魔法だらけの家』(原題: Encanto)。 2021 年のアメリカ映画。 ミュージカル。 不思議な魔法の家族。 Frozen とか Coco とかみたいな、ディズニーアニメーションらしい展開。
16 進数表記に $ を使うのは Borland がはじめた拡張みたい。
へぇ。
Extended Pascal なる仕様もあって、そちらは 16# のように基数をそのままプリフィックスに使うそうだ。
へぇぇ。
C は、標準 C ライブラリがないと単純な入出力さえ満足にできない言語で、プログラムの先頭にはいくつもの #include が並ぶのが定番。
バイトスワップみたいに専用命令があれば活用したいから、各コンパイラーが大量に独自のビルトイン関数を投入していて、ヘッダーファイルで吸収されている。
Pascal とか、昔高校で習った FORTRAN とかは、標準で入出力はついている。
これはまぁ、どっちがいいか悪いかという話じゃなくて、そういうもの、ってことなんだけど、unit を書かなくてもけっこういろいろできるんだなー、とは思った。
(たぶん標準で読み込まれるものがあるって話っぽい。)
Free Pascal コンパイラーが生成する Linux のバイナリは、きのうまでにいくつか書いた FizzBuzz のプログラムみたいなのだと、statically linked で生成される。 つまり libc みたいなのが動的リンクされない。 Windows だとそうはいかないはずだし、Lazarus で作った GUI アプリケーションも動的リンクだったが、そういえば昔 Delphi が流行っていた頃にも、Delphi で作られたアプリケーションには別途ランタイムライブラリを入れる必要がない、みたいな話があったね。 最近だと Go という言語はやはり statically linked 方式になっているが、これも動的リンクになる場合があるようだ。
C と比べると、Pascal は型の種類が豊富な感じはする。
特に subrange で特定の範囲を指定できるのはおもしろくて、array に subrange が使えるのも良いし、Free Pascal だと bitpacked を使えば subrange を表すのに必要な最小ビット数を割り当てた record も作れる。
例えば month は 1 から 12、としておけば、bitpacked で 4 ビットで済む、みたいな。
(まぁ、数字を小さくはしてくれないみたいなので、101 から 112 としたら 7 ビットになってしまうけどね。)
C は特に大昔の C は struct のメンバーなんかまで名前空間が共有という状態だったし、もちろん今はそれは違うんだけど、enum のチェックがあまりされない (int の値として扱えてしまう) あたりはその名残かなという感じがある。
enum に対応する配列を作るというのもやるけど、最後に特定の名前を割り当てておいて、その名前を配列の要素数として指定して宣言する、みたいな感じで、間違えて他の enum の名前を書いちゃっても気づけないんだよね。
そのへんは Pascal のほうがいいところかなと感じている。
Pascal は変数宣言をプログラム (関数等) の前に済ませないといけない。
これはたぶん、長年の拡張がされてきた今でもそうなんじゃないかな。
C は { } ブロックの先頭であれば昔から好き勝手に宣言することができた。
これはまぁ、どっちがいいのかは判断が難しいところかな。
C でも関数の先頭に変数宣言をまとめているプログラムも多いだろうし。
Pascal のように強制されると、ローカル変数がてんこ盛りになる前に、ちゃんとルーチンをわけよう、みたいな気持ちになるところもあるかも知れないし。
時間に追われている時なら、動くルーチンをブロックごとコピーアンドペーストして書き換えて完成させる手が C なら使えるし。
C の場合 while はすべて for で書けるが、Pascal は while と for を明確に使い分けている。
for のループの中に goto しちゃいけないし、for に指定した変数をループの中で書き換えてもいけない。
C の for はそういう制約がなくあまりにも自由度が高いので、すっきりしているけどこれ全然 for じゃないよね? みたいなコードも書けてしまう。
アルゴリズムの教科書に Pascal が使われるのはそのあたりかも知れない。
C の for の定番は for (i = a; i < b; i++) 方式の書き方だろうけど、これの <= バージョンは桁あふれ時の無限ループに注意が必要なのに対し、Pascal はその心配なく確実にこなしてくれる。
実は、きのう書いたプログラム、with を使う前のバージョンを書いてコンパイルした時、一発でコンパイルが通り、一発で動作してしまった。
いくら前に C++ 版などを書いていたといっても、なかなか珍しい経験だ。
何か Pascal にそういう特性でもあるんだろうか?
と思ったが、考えすぎだな。
あまりやる機会がなかったけど、C でも、関数内での型の定義は可能なようだ。
例えば struct hoge を関数内で定義すれば、それは関数内に閉じられたものになるらしい。
関数内というか、ブロック内か。
そういう場合たいていは名前無し構造体にしちゃうからね、あんまり考えたことがなかった。
typedef もそうなので、Pascal で type t0 = packed array[1..5] of char; みたいなのを procedure ローカルとして書いたのを、C でもそのまま typedef char t0[5]; みたいに関数内で定義できるというわけだ。
晴れ時々曇り。 寒い日。
バイクに乗った。 エンプティになったので給油した。 最後に給油したのがつくばだった。 あんまり燃費伸びていないな、と思ったらオドメーターの記憶ミスだった。 ま、オドメーター記録だと、たまにミスっても数回分ぐらいを平均するとそれっぽい数字になるけど。
ホンダの NX400 の情報は不明だが NX500 の情報は出始めていて、YouTube にイギリスの情報が出ていたけど、エンジンは CB500X と基本同じみたいな説明になっていたな。 つまり 180 度クランクなのかも。 なので、デザインの変化、くちばしが短くなったのが好きか嫌いかみたいな、そういう話みたい。 自分は 400X のほうが好きかな。 ヘッドライトが減光側とそうじゃないので上下とか左右とかに分離しているのはなんか好きじゃないんだよね、左右は BMW とかヤマハとかにありがち。 あとはいろいろディジタル化が進んでいくみたいで、左手で何か操作できるものが増えるみたいだが、そのあたりの使い勝手はまだ熟成されていないんじゃないかという予感がするw NC750X の左手でモード切替するやつもいまいち使いやすくはなかったしなw
テレビアニメ『呪術廻戦』。 41 話。 オープニング無しで話が進む! しきがみ? と呪霊に乗っ取っられた主人公が渋谷の建物を次々に破壊するw ここに来て、主人公が取り込んでしまった呪霊のおそろしい強さをたくさん見せつけられている。 何もかもが異次元じゃないか...
テレビアニメ『葬送のフリーレン』。 11 話。 お礼をもらって、先に進む。 魔法の試験が必要w 冬。 厳しい冬。 スクワットエルフ。 この声は高橋涼介の声と同じ役者さん... 天地創造の女神様。 冬を越して、先に進む。
テレビアニメ『オーバーテイク!』。 7 話。 主人公のフォトグラファーはどこへ。
F1 ラスベガス GP 予選。 アメリカ合衆国ネバダ州のストリートコース、現地の夜開催なんだそうで、日本時間で 17 時に予選開始だったから、現地の真夜中の 12 am じゃんw 映像からあんまり観客の盛り上がりが感じられなかったのはそのへんの影響があるか。 あとめっちゃ寒そう。 あの厳ついメカニック達が長袖だよ。 決勝は日本時間 15 時開始だそうで、現地時間は 10 pm だから少しマシである。 ...そう、なんと現地時間で土曜日が決勝になっているという、超珍しいグランプリである。 角田はトラフィックに引っ掛かってタイヤを温め損ねたとのことで予選最下位。 リカルドは Q2 にはギリギリいったものの 15 番手だったので、マクラーレンが 2 台 Q1 脱落の運に恵まれたところもあるだろう。 ハミルトンとペレスが Q2 で脱落。 最後はフェラーリが 1-2 を決め、フェルスタッペンが 3 番手に続く。 せっかく速いフェラーリの 1 台は、free practice 中にマンホールのふたが取れたのに当たって何もかもが壊れてしまい、パワーユニット交換になって 10 グリッド降格という何とも残念な話になっている。 アメリカ人ドライバーのサージェントが速さを見せて Q3 に進出していた。 出身地のフロリダ州からすればだいぶ離れている場所だけど、それでも母国で何度もレースがあるのはうれしいだろうな。 一時期は成績が上向かずもうだめかと思ったサージェントもこのところ調子が良くなっている感じなので来年も見られるかも知れない。
スポーツカート耐久レース。 御殿場。 5 時間耐久レース。 ハイスピードコース。 4 人チームから参加。 ドライコンディション。 9 位。
寒くなってきたので路面温度が低くタイヤのグリップが弱い。 それで全体的に難しいところがあり慣れるのに時間が掛かった。 特に 2 回目のスティントだったかな、左に曲がる時にアンダーステアっぽいということを理解するのに時間がかかり、8 コーナーで何度もクリッピングポイントを外し続けた後でやっと気づいて、左コーナーを丁寧に走らせるようにしたら急にタイムがよくなった。 レース後早くも筋肉痛。
車で。 寒かったからね。 東名道は工事で交通規制があるとのことで、中央道・東富士五湖道路を使った。
帰りはお腹が空いていたので、めしを食ってから、旧 138 号線 (今は別の番号が振られている) を通ってみた。 旧 APG の前の道。 懐かしい景色に、高架道の橋脚が生えている。 こんな風になっていたんだ。 案内は不親切で、基本的に新御殿場こっちという案内しかないw そんでもって山中湖経由で道志みちに出て、道志みちをスーッと走っていたらトイレに行きたくなって、あのコンビニに駆け込んだ。 そっからは国道 16 号に出て北野街道に出て、うっかり日野に登ってしまったが、それで国道 20 号に出て帰った。
晴れ。 寒い日。
F1 ラスベガス GP 決勝。 スタートでフェルスタッペンの俺様コース外オーバーテイクwww 今回はペナルティ出た。 ま、ペナルティ消化しても勝ったんだけどね、この人は。 角田はスタートはよかったがペースがなく、最後はトラブルでリタイアした。 ピアストリがまた新人らしからぬレースを見せてくれた。 下位スタートだったのに 10 位入賞とファステストラップポイント。 ポールポジションスタートのルクレールが、3 位まで落ちていたが、最終ラップで 2 位を取り返した。 ルクレールは熱いレースをしていたね。