女同士で浮気って言う必要あるの?

先日発売された2つの小説が話題になっていて……

人妻教師が教え子の女子高生にドはまりする話2 (KADOKAWA)

彼女のカノジョと不純な初恋 (KADOKAWA)

同じ出版社で発売日が同じ、そして女同士の恋愛と浮気である。

同じ出版社といってもライトノベルのガリバーであるKADOKAWAだから普通……

と思いきやどっちも電撃文庫ということでレーベルまで同じでしたか。


「人妻教師が教え子の女子高生にドはまりする話」というのはタイトルがひどすぎるが、

以前もカクヨムネクストの話で話題にしてますね。

小説投稿サイトのプロ部門

上下巻構成で終わると思っていたら、収まりきらなかったようで3巻構成になりそうと。

既婚の高校教師、苺原樹が教え子の女子生徒に誘われるがままに手を出してしまうという内容である。

そんなことあるか? という感じはあるが、そこは小説ということで。うまく書いている。

2巻の紹介が「こんにちは! 私淫行教師の苺原樹! 十歳年下の教え子と関係を結んで平気な顔で教壇に立っているどうしようもないやつだよ!」とあって、

これは実際に小説の中で出てくる文言なのだが、ここにこの話の特色が現れている気がする。


「淫行教師」という部分は全く言い訳が立たないのですが……

高校生相手に女同士だから問題ないとは言えないでしょう。

一方で夫がいる中で女同士で付き合うことを「不倫」と重く考える必要があるのかというのは意見が分かれるところはあるかもしれない。

表に見える部分だけ集めれば、教師と生徒が公使ともに親しくしているぐらいの話で、

そこには教え子のプライベートな事情もあるということで。

2巻の結末はまさにそんな話だった。(ネタバレになるから書かないけど)

表向きはそんなにおかしな話ではないが、「不倫」と考えれば危ないというやつ。


逆に「彼女のカノジョと不純な初恋」は、紹介文に「恋愛感情がなければ浮気じゃない」なんて書いてあるけど、

これは浮気ではないかと言われる中で、友人関係の範疇であると言い張る話である。

そもそも背景として 碧海つかさ と 狭山玲羅 はよく知られた「カノジョ」同士ということがある。

女同士で付き合っていると考えられている。(実はここに疑義があるのでは? と書かれていたが)

で、この2人、元々は同居していたのだが、つかさが家を飛び出してきたところ、

事情があり、高校生でありながら1人暮らししている 拝島雪 の家に転がり込んできたと。

で、女同士で付き合っているとされる人と同居して親しくするのは浮気ではないかという指摘があり、

実際そういう見方もできる……というか際どいところはあるというか、言い訳できない部分もあるが、

先ほど書いたように表向き「恋愛感情がなければ浮気じゃない」としているところである。


で、この浮気ではないかと言っているのが、雪の友達である久留米弓莉なのだが、

口絵のキャラクタ紹介に「ユキに強い感情を向けている」とあるように、

この指摘は表向きは友人からの忠告に過ぎないのだが、おそらく別の思惑もあって……

転がり込んできた女に友人を取られることへの危機感なんでしょうよ。

「最近友人づきあいが悪いじゃないか」というような話なら一般的な友人関係にもありそうだが、

それを越えて独占したい人間関係ってもはや……ということなんですね。

玲羅-つかさ、つかさ-雪、雪-弓莉 の関係それぞれに着目してみると、

表向き恋人同士、友人同士、その実態は両思い、片思いの恋愛関係というのが交錯して大変煩雑である。

あとがきに「なぜかとても湿度が高い作品になっていました」とあった通り。


「夫がいる中で女同士で付き合うことを『不倫』と重く考える必要があるのか」と書いたが、

これは意見はいろいろあると思うが、男女間の関係と男同士・女同士は別という考えは一定ありそうである。

実際、男同士だからそれは別という考えを聞いたことはあるような気がする。

それで当事者同士が納得してしまえばそれで全部済んでしまうと。

もっとも「淫行教師」という部分は教員としての倫理とか、

現代的な言い方では「不同意性交等罪」への該当性とか問題はありますけど。

(かつての強姦罪だが、2023年以降、この名前になってからは女同士でも適用される余地が生じた)


そもそも浮気はいけないという考えはどこから出てきたのかという話もある。

さっき弓莉が浮気ではないかと忠告するのは「友人を取られることへの危機感」か?

なんて書いたけど、わりとそういう素朴なところが起点なのかもしれない。

ただ、男女間、特に婚姻関係となれば、より大きな問題がある。

まず重婚が禁止されているので、2つ以上の婚姻関係が同時に存在することはできない。

重婚があると絶対に困るなと思うのは嫡出推定である。

生まれてきた子の母親に2人以上夫がいたら嫡出推定なんて成り立ちませんよね。

(世界的には一夫多妻制が制度化されている地域はあるが、その逆がおおっぴらに行われている話は聞かない)

夫婦間には強い扶養義務がありますが、配偶者が2人以上いた場合には実現性にかなり問題がありそうで、

一夫多妻制が認められている地域でも扶養義務を確実に履行できることが要件にあったりする。

不貞行為が糾弾されるのも、親子関係や扶養関係というところへの憂慮が大きいんだと思いますけどね。

あとは税制や年金で優遇のある配偶者が2人以上いては不公平というのもあるでしょうしね。


で、この上に書いたようなことの起点がどこにあるのか考えると、

夫婦間に子供が生まれる可能性があるというところにあるんじゃないかと。

だから、結婚は嫡出推定や親権などの親子関係に影響を与えるし、

出産・育児などで仕事から(一時的かもしれないが)離れるのも珍しくない中で、

強い扶養義務、所得税・住民税の控除、社会保険料の軽減であったり、

配偶者の死後においては最低でも1/2の法定相続分、1/4の遺留分があり、

それに伴って相続税も軽減されることとなる。

制度面の話ばかり書いたけど、それ以外の慣例を生んでいる背景の多くはそこだと思いますよ。


じゃあ、男同士・女同士には成り立たないねという考えもあると思うんですよ。

男同士・女同士の恋愛関係があってもよいけど、

そこに男女間の関係にあるルールを当てはめてもうまくいかない可能性は大いにあるんじゃないか。

それでだいぶ前から同性婚に関する議論がとても危ういなと思っているんだよね。


というのも同性婚が制度化されたら、専ら相続時の優遇を目的に使う人が出てくるんじゃないかと。

もちろん男同士・女同士であっても相続が安定的にできることは、

同性婚を切望するひとにとって切実な課題の1つであるとは理解している。

でも、果たして節税同性婚なんてのが問題になったときに、世論は納得するのか? と聞かれると、

僕はそうもいかないんじゃないかなと思うんですよね。


本当に不公平かというと必ずしもそうとは言えないんだけど。

というのも男女間の結婚であってももっぱら節税目的で行われる可能性は存在する。

さっき結婚についての制度や慣例の多くは夫婦間に子供が生まれる可能性から来ているのではと書いたが、

夫婦間に子供がいるとは限らないし、おおよそ子供が生まれるとは思えない結婚でも成立するし、

親子関係に関わるものは関係ないにせよ、それ以外の効力は同様である

同性婚だってそれと同じことだから問題ないし、

重婚の禁止などの規定も適用されるだろう特段不公平とは言えない。


でも、なんやかんや言っても男女間だといろいろな慣例があって、

制度上可能だとしても踏みとどまるようなケースが多いと思うんですよね。

ところが男同士・女同士は別とすっ飛んで「節税同性婚」が容易に成立する可能性はかなりあるんじゃないかと思うんですよ。

で、そこに世論が納得しない場合、何らかの制限が必要になるかもしれないが、

男女間の結婚と同性婚に大きな差が生じるような制度は作れないでしょう。

子供がいることに着目するのか、婚姻期間に着目するのか、いろいろ考えはあると思うけど、

従来は全く問題なかったはずの男女間の結婚に問題が生じることになる。


ところで「節税養子」という言葉もありますが、

相続時の優遇を目的として成人同士の養子縁組が行われることは日本ではよくある。

というか日本の養子縁組のほとんどが配偶者の子に対するものと成人同士のものなんじゃないかね。

(養子縁組には家庭裁判所の許可が必要だが、この2つのケースは家庭裁判所の許可が不要である)

成人同士の養子縁組は子供の福祉に全く寄与しないので本来の趣旨から逸脱しているのだが、

日本では後継者を養子にして継承するということが伝統的に行われてきた。

現在もこの考え方は日本社会においては広く受け入れられているので、

節税養子というのも一定の制約のもとに公然と認められている。


そういう背景のない節税同性婚はおそらく社会的に受け入れられないんじゃないですかね。

そこをつぶす制度変更をするかどうかというのは政治的な判断だが、

そこをつぶすと男女間の結婚関係の慣例を多少なりとも破壊しかねないので、

そこが受け入れられるかというのは難しい問題ではないかと思う。

夫婦間に子供がいるような典型的なケースは従来通りカバーできる制度にすると思うが、

そこからこぼれる夫婦は不適格なのかという人は絶対に出てくるわけで、

そこに納得しない人が同性婚を制度化させるように仕向けたひとを批判するのは目に見えている。


話は長くなってしまったが、いろいろ突き詰めると難しい問題がある。

小説の話に戻ると――

「人妻教師が教え子の女子高生にドはまりする話」の特徴というのは、

男女間でやれば「不倫」ということを女同士でやって、これは不倫だと自らを責め立てるところにあると思っていて、

でも「後悔自体は一切ない」とあるように、そういう選択は普通にあるなというところが妙である。

「彼女のカノジョと不純な初恋」というのは、

友人関係と主張できる女同士の関係だとか、浮気をすれば糾弾されるような女同士の関係だとか、

なんとでも言えてしまうという要素がいろいろなところに現れている。

そんな中で関係を深めていくというところが面白いのではないかと思う。

どっちも大爆発エンドという可能性もありそうな作品ですけど、

何らかポジティブな結果には終わるんじゃないかと期待しているところである。

「彼女のカノジョと不純な初恋」の方は続刊出るか知らんけど。

リアルタイムOSのスタックの使い方

スタック消費量の計算をしないといけないということで、

コンパイラの設定をいじくってスタック消費量を出せるようにしていた。

思ったよりめんどくさい……というかある事情により超めんどくさいことになっている。


最初はスタック消費量なんてどんぶり勘定でいけると思っていた。

どんぶりサイズのスタックを用意しておいて、消費量の見積もりが湯飲み一杯分なので、

割り込みなどで見積もりに入っていないスタック消費があっても余裕余裕と。

ただ、思っていたより消費量が多い処理もあって、真面目に考えないといけないかもと。

果たして、割り込みなどで消費するスタック量はなんぼほどなのか。


そんなわけで使っているリアルタイムOSの資料を見ていたら、

なるほどこんな風にレジスタの退避をしているのかと。

OSでレジスタ退避が必要となるシチュエーションは大きく3つ、

自発的なディスパッチ、割り込み、割り込み後の非自発的なディスパッチである。

その上でレジスタは呼び出し先の関数で壊してよいスクラッチレジスタと、それ以外に大別される。

Cでレジスタを使ってやらかしてる

自発的なディスパッチ処理というのは、システムコールをきっかけに発生するディスパッチで、

tslp_tsk(SLEEP_TIME);
foo();

と、SLEEP_TIMEだけタスクの実行を休むシステムコールを実行して、

復帰後にはfoo(); という処理をする場合、この間にスクラッチレジスタが吹き飛ぶことを前提としてコンパイルが行われる。

なので、他のタスクに切り替える前に保存するのはスクラッチレジスタ以外だけでよいと。


この逆に割り込みで保存する必要があるのは割り込み復帰に必要なレジスタとスクラッチレジスタである。

なぜならば割り込みハンドラの中でスクラッチレジスタ以外を使う場合、

割り込みハンドラの責任で退避・復帰を行うからである。

一般的に割り込み時のレジスタ退避はそういう考えで行われるみたいですね。

で、割り込みハンドラを抜けて元の処理に戻る場合は、

スクラッチレジスタを復帰して、割り込み復帰に必要なレジスタを復元するわけだ。


ところがOSでは割り込みをきっかけにしてタスクの切替を行うことも多い。

タイマ割り込みをきっかけにして優先度の高いタスクが動き出す場合など。

このような場合はスクラッチレジスタ以外も退避する必要がある。

結果的には全レジスタを退避させることになるのだが、

スクラッチレジスタとそれ以外をグループ分けしてモジュール化することで、

多重割り込みなどにも効率的に対応できる仕組みになっている。


今のリアルタイムOSを使用する前に、他のOSのソースコードを見ていたことがあり、

こういう処理ってアセンブラで書くしかないこともあるんだけど、

なんでこういう処理にやっているのか理解しにくくて困った覚えがある。

現在使っているOSでは退避と復帰が一対一対応するようにアセンブラで書かれていて、

いろいろな構成やシチュエーションに対応できるようにモジュール化されていて、

解説も相まってかなり読みやすいなと思った。ありがたいですね。


で、退避させるレジスタのサイズを見たら、案外多いんだよね。

割り込み復帰に必要なレジスタ+スクラッチレジスタ+それ以外のレジスタとフルセットで退避させるとこんなに行くのかと。

冒頭に書いたようなどんぶり勘定が成り立つなら全く問題ないが、

真面目に考えないといけないものもあるかもなぁと。


あと、多重割り込みですよね。これがくせ者である。

割り込みがあるごとにレジスタ退避に割り込みハンドラ実行にスタックを使う。

1回1回が少量ならデフォルトのスタック確保で十分だが、

思っているより多い……となってしまった。

というか、これは設計思想が合ってない気がするな。

移植という性質もあり、今さらどうしょうもないんだけどさ。


で、これを書いているときに計算の設定ミスに気づいてしまった。

もうちょっと厳密に計算できるが、計算結果が増えるか減るかわからん。

車庫証明がないと渋滞が起こる?

Cities:Skylines2で最初に作った都市も人口42万人にも達し、

これ以上やるのも難しいかなと思いつつも、もう少しできることはあるんじゃないかと。

で、市内各所で渋滞が起きているのだが、ある時はここで渋滞が発生し、

ある時はここで渋滞が発生し、と渋滞が起こる場所が転々としていることに気づく。

で、いろいろ観察していたのだが、原因は駐車場を探す車による渋滞だったらしい。


中密度以上の住宅には駐車場が備わっていない。

この場合、車を持つことを希望する住民は車を路上か駐車場に停める。

このゲームはあまり気にせずに道路を引くと路上駐車が発生する。

日本の感覚では路上駐車が基本というのは変な感じがするけど、

アパートに駐車場がないというのもそれはそれで変な話である。


ただ、それ以上におかしいのは、駐車場を探し回って右往左往する車が多数発生することである。

駐車場のアテが付かない場合は車を持たないというロジックは存在するらしいが、

1台でも駐車スペースに空きがあれば、車を所有できると考えてしまうそうで、

駐車場のわずか数台の空きをめがけて何十台も押しかけるわけである。

当然、駐車できるわけはないので、大半の車が引き返して他の駐車スペースを探す。

大抵の場合は他の駐車スペースに空きが1台は空きが存在するので、そこをめがけて走り出す。

これが渋滞が起きる場所が転々としていた理由であり、転回が多数発生する原因でもある。


日本では車庫証明という制度があり、自動車を保有するには使用の本拠(通常は自宅)の近くに保管場所がなければならない。

「保管場所を使用できる権原を有すること」という要件があって、

自己所有なのか月極契約なのかはさておき、必要時には駐車できる必要があるので、

通常は保管場所から車を出すと、帰ってくるまで空きであるのが通常である。

ところがこのゲームは駐車場所の裏付けがなくても車は所有できるし、

駐車場所から車を出すと、駐車場所を他の車に奪われてしまうのは普通である。

結果として自宅近くの駐車場所には戻ってこられない可能性もある。

こうなるとどこでもいいから駐車場所を探して彷徨うことになる。


SimCityで高密度住宅から1000台とか車が出てきて、明らかにおかしいだろと思ったことはあるけど、

住宅には必ず駐車場を備えているというモデルであれば、

とりあえず自宅には車を停めることはできるので上記のような問題は起きない。

ところがCities:Skylinesシリーズでは自宅に駐車場があるとは限らないし、

外部に駐車する場合に日本で言うところの「保管場所」としての駐車スペースと、

目的地の駐車スペースを区別する仕組みが無いので、駐車スペースが見つかる保証がないのである。


この問題の打開策はいくつかある。

1つは自宅付近に十分な駐車スペースを用意するという方法。

低密度住宅であれば敷地内に駐車場があるので容易に実現できる。

「駐車場付き道路」という多くの車両が路上駐車できる道路もある。

ただ、これだけだと中密度住宅にも追いつかないのが実情だと思う。

入居時などに駐車したい車が殺到すると、駐車スペースを探して右往左往して渋滞が発生して、

これがなかなか引かないで公共サービスにも影響を来すということはあると思う。

低密度中心でなければ取り得ないアプローチかもしれない。


逆に全く駐車スペースを用意しないというアプローチもある。

駐車場を作らず、道路も路上駐車できないものばかり作るわけである。

3車線道路、街路、砂利道、高速道路などを選べば路上駐車できなくなる。

2車線道路などは街路樹・広い歩道・草地を付加することで路上駐車を封じることができる。

こうして徹底的に駐車スペースをなくしていくと、どこにも駐車できないという判定になり、

低密度住宅などで駐車場のアテのある車以外は存在しなくなるわけである。

大都市を目指すならこのアプローチが楽には違いない。


で、もう1つ代表的なアプローチとして、郊外に駐車場を設けるという方法がある。

郊外に車を停めて地下鉄などで移動するという形にするのである。

十分な数の駐車スペースがあれば、駐車場を求めて彷徨う車もいつかは駐車できる。

市街地に十分な駐車スペースを設けるのは難しい面もある。

例え十分なスペースがあっても右往左往する車で大渋滞となり様々支障がある。

後で書くような事情もあり、どうしても駐車場付近の渋滞は避けられないので、

渋滞対策の容易性や、公共サービスへの影響を考えれば郊外に駐車場を集めるのが理にかなっているわけである。


最初は2番目に書いた方法がよいかと思ったが、それはそれでリアリティがないので、

3番目に書いた郊外に駐車場を設けるアプローチでいくことに。

郊外の3つの駅前に立体駐車場をずらりと移設・新設していく。

高速道路に直結したところにある駅なので、車を集めるにも好都合である。

立体駐車場はアップグレードすると300台まで収容できる。

維持費が比較的高価らしいが、すさまじい黒字なので気にしない。

立体駐車場以外の既設の駐車場は削除、路上駐車できる道路はできるだけ差し替えていく。


そんなので市街地からは駐車場を求めて彷徨う車はほぼいなくなり、

駅前は駐車場を求める車であふれ、その渋滞は高速道路の本線まで伸びるものも。

駐車場までの道路を長くするなどの調整をして、他への影響を軽減しつつじっくり待つ。

車の動きを観察すると、人気の駐車場に殺到して、満車になって別の駐車場に並び直しをしたり、

列から抜ける車が何台もいると思ったら、路上駐車を潰せてなかった道路に向かっていたり……

数量として充足していてもなかなかスムーズに停めてくれないのが実情である。

どうしても渋滞が長引くことは避けられないので、郊外で処理した方がよい。


最終的に3つの駅前に計50棟の立体駐車場が並ぶこととなった。

42万人に対して15000台の公共駐車場を用意したという形である。

そこから自宅などには地下鉄(大半は高架だけど)・徒歩などで移動する。

で、おそらく通勤・買い物などの日常生活ではほぼ自家用車は使っていないはず。

なぜならば目的地にはほぼ駐車場がないからである。

一部には自家用車での通勤もあるが割合としては少なく、地下鉄・徒歩が主とみられる。

このため入庫する車(並び直し含む)は混むが、出庫する車で混むという光景はみられない。

市外への移動など、どうしても車が便利な移動では活用しているようだが、全体としてはわずかである。

冒頭で書いたように駐車場を探す車による渋滞が多くを占めていたことの証拠でもある。

まだしばらくはこの都市でやっていけそうだなと思った。


地下鉄がある現在ならこのアプローチは全く問題ないけど。

地下鉄・鉄道などができる以前の公共交通といえばバスだろうけど、

バスは利用者が多くなると乗降で混雑し、数珠つなぎになってしまう。

郊外の駐車場と結ぶためのバスを運行するとどれぐらい混むのかわからないけど、

あれもこれもバスで移動となるとけっこう大変ではないかと思う。

何もかも自家用車では道路の渋滞が大変だが、バスばかり使われてはバスの運行の妨げになる。

となるとある段階までは1番目に書いたような駐車スペースを分散させるアプローチがよいのかもしれない。

いずれにせよ駐車場を探す車による渋滞が延々続くのは避けたいのだから。

コードサイズが肥大化した原因

プログラムにある改造を施していたらビルドが通らなくなったと相談があり、

リンカでのエラーで、おそらくプログラムサイズの問題なんだろうなと、

調べてみたら異常にコードサイズが巨大な関数があって、

一体何が原因かと思ったらバイトオーダーを入れ換えるマクロのせいだった。


こんなやつね。

#define SWAP32(v) (((v) & 0xff000000u)>>24)|(((v) & 0xff0000u)>>8) | \
                   (((v) & 0xff00u)<<8)|(((v) & 0xffu)<<24))

こんな処理が愚直に展開されてしまっていたと。

これが何回も何回も出てくる関数がとんでもないサイズに肥大化していたと。

で、さすがにおかしいだろということで確認したところ、

最適化レベルをNoneにしていたらしく、それも相まってすごいサイズになってしまったらしい。


確かにマクロというのは使う場所に都度コードを展開するというものなので、

何度も何度も使うとコードサイズが肥大化する原因にはなりうる。

ただ、コンパイラの最適化が期待できる部分もあり、

上記のマクロにしても a=BSWAP(0x12345678); のような使い方だと、

定数演算はコンパイラで済ませて、a=0x78563412; に相当する処理になるなど、

マクロを使うことによる特有のメリットがあると言うこともまた1つの側面である。

そこの見極めが必要だったんじゃないのというのは1つありますが。


そもそも冒頭に書いたような処理は専用の命令を持ってるCPUが多いわけで……

#define BSWAP32(v) ({ unsigned int r; \
__asm__("rev %0, %1" :"=r" (r):"r" (v)); r; })

のような書き方の方がよかったという説はある。

コンパイラの最適化でこういう置換をしてくれることもあるが、

最適化レベルを下げていたのでそういうのも期待できなかったと。

この話にはさらに続きがあるんだけど、それは書けない話なので書かない。


コードサイズの肥大化という形で問題が顕在化したわけだけど、

よくよく考えてみるとコードサイズが大きい=実行時間が長くなるという構図である可能性も高く、

新規に挿入したマクロでコードサイズが激増したということは、それだけ実行時間が増えるんだろうなと。

コードサイズの増加だけの問題ならばマクロから関数呼び出しに変える方法もあり、

コードサイズへの影響はかなり軽減できることにはなる。

ただ、実行時間の増加という観点ではほぼ変わらないわけである。

そう考えると正直どうなのかなと思うところもある。


バイトオーダーの変換に限らず、いろいろな処理をマクロでやっていて、

ほぼコンパイラで静的に処理されるだろうと期待しているものも多いが、

中にはけっこうなコードサイズの処理になっているものもあるのかもしれない。

かなり衝撃的な話でしたね。

ラブラッドアプリがない人の献血

金曜に献血に行っていた。平日にしてはえらい混んでた気がする。

そこで掲出されていたのだけど、来年1月から献血カードの発行・更新をしなくなり、

ラブラッドアプリを使用しての受付が基本になるそう。


こうなると気になるのがアプリを使えない人への対応である。

アプリがないと献血できない? そんなわけはないでしょう。

何年も前に献血したことがあるような……という人が献血会場に来て、

じゃあ受付用紙に情報を書いてくれと言われて、それを元に検索して、

ありましたねと言われて献血している人はナンボでもいるわけである。

それは来年以降も変わるわけはない。献血久しぶりの人を拒むわけはないのだから。


今後、アプリがない人のワークアラウンドは明示されるかもしれないが、

おそらく都度、氏名・生年月日などで検索するということになるのだと。

取り違えが心配だが、最近は指静脈情報での認証を行っているのでおそらく問題はないだろう。

明確に変わるのは献血カードの発行・更新を行わなくなること。

あのリライタブルカードのシステムを維持するのをやめるということで、

次回献血可能日などをカードに記載して教えるということはやりませんよと。

代替手段として献血者コードを書いた紙切れを渡すようなことはあるかもしれない。

これでも献血時の本人確認としては一定の意義がある。

次回献血可能日は自分で計算するかラブラッドのWebサイトで見るか、それで勘弁してねと。


アプリへの一本化はどうかと思うところはあるけど、

ラブラッドアプリは便利であることは確かである。

1つはアプリからサクッと予約ができること。

昔は予約という概念がなく出たとこ勝負だったり、電話をかけて予約したり、

そんなのだったけど成分献血だと予約しないなんてあり得ないよね。

さすがにバスでの献血を予約する人はそうそういないだろうけど。

もう1つはやはり問診の事前入力である。これは本当に楽である。

15分前までに入れておかないと受付時に反映できないのが注意だが。


ラブラッドアプリを多くの人が利用するようになっていて、

リライタブルカードで献血カードを発行する意味が薄れていて、

ゆえに発行・更新を停止するというのは、理解できる話ではあるが、

全ての人がその恩恵にあずかれるというわけではないのも事実。

で、似たような話があったなと思ったんですよね。

それがETC専用のインターチェンジを暴力団員が利用できるかという話である。

高速6社「暴力団員もETC使わず走行可に」 憲法違反の訴えに反論 (朝日新聞デジタル)

暴力団員はクレジットカードを作ろうとしても拒まれる状況にあり、

ETCパーソナルカードというデポジット式のカードでさえ拒まれる状況。

一方で都市高速を中心に既存の料金所がETC専用化される流れもあり、

こうなるとヤクザは高速道路を使えないという状況にもなりかねない。

それっておかしいんじゃないのという話で、本当に道路が使えなければ確かに問題である。

しかし、高速道路各社の回答としてはサポートレーンに入って料金を後払いするという方法はあると。

この方法ならばETCがない人でもETC専用出入口が使えるという理屈である。

ETCで何らかトラブルがあり、Web・電話で申告してETCカードに請求してもらったり、後で料金所事務所で払ったり、

そういう手続きを行うことは普通にあるわけで、できない話ではないが、

それが正当な手段ですよと言われてしまうと、そうなの? とはなる。


ラブラッドアプリのない人の献血ってのも同じような話だと思いますね。

都度検索すればアプリがなくても献血することはできるが、

それが当然となる人がいていいのかという話は当然の指摘である。

でも、アプリがないひとを拒むことはないのはほぼ間違えない。

【令和8年1月5日(月)から】献血カード・献血手帳の新規発行および更新の終了について (日本赤十字社)

ここに「アプリやカードをお持ちでなくても献血の受付は可能ですが」って書いてあるよね。

所得税の申告で手入力は少なくなった

所得税の申告書類が揃っていることに気づいたのでe-Taxでサクッと申告した。

確定申告の期日前だが、そもそも還付申告なので関係ないし。


で、今回の提出書類の多くがXMLデータだった。

GMOクリック証券の年間取引報告書はXMLで受信にしていたし、

市町村・道府県への寄付金については、各プラットフォームがXMLを出している。

ふるさとチョイス、さとふる、au PAYふるさと納税、それぞれでダウンロードできた。

XMLデータを食わせていくと、これらの項目はほぼ自動入力である。

(譲渡所得は他の費用がないかなど手で入れる項目は多少あったが)


結果として他の入力項目は給与の源泉徴収票と、

それ以外の寄付金(日本赤十字社・国立文化財機構)だけだった。

給与の源泉徴収票は入力項目が多くて煩わしいのだが、

実は事前登録しておけば源泉徴収票のデータが自動入力される機能があるそう。

給与所得の確定申告がさらに簡単に!【利用者用ページ】 (国税庁)

よくわからん書き方だが、e-Taxの「本人確認/情報取得希望」を登録しておく必要がある。


ただ、現状はかなり穴があって、それは勤務先から税務署に源泉徴収票が電子的に送信されている必要があること。

源泉徴収票というのが問題で、給与の源泉徴収票は支払額500万円以下の場合は税務署に送信する必要はない。

ただ、その場合でもほぼ同じ内容を記載した給与支払報告書を市町村に提出する必要があり、

多くの場合はeLTAXという地方税ポータルサイトで電子的に提出されている。

これを元にして住民税の計算を行い、6月に住民税額が届くわけである。

ほぼ同じものをe-Tax(税務署)とeLTAX(市町村)に提出するのは無駄ということで、

eLTAXに提出すれば税務署への提出も兼ねるという制度変更がなされるようだし、

現状でもeLTAXへの送信データ作成時に500万円以下の分も含めてまとめてe-Taxのデータにして提出することはできる。

なのですでに解消されている場合もあるし、将来的にはほぼ解消する見込みである。


あと、僕は職場の年末調整で提出したけど、保険料控除の書類も手入力になりがちだが、

こちらも実はXMLでの受信が可能になっていることがあって、

全国生協連は昨年分からXMLでの発行が可能になったそう。

現状は職場での提出方法が紙での提出だから、郵送されてきたのを出しているけど、

職場でもXMLデータで提出に対応しているところはあるかもしれない。

そもそも所得税の申告をするのなら会社に紙で提出する必要が無いのはそうなのだけど。


その他の寄付金控除もXML形式で作成することはできるが、

ニーズがどの程度あるかという問題はあると思う。

あと、住民税の申告を兼ねるという点では条例指定か否かという情報も必要だが、

これはe-TAXでは自動判別できないので手入力になるはず。

圧倒的にニーズの多い市町村・道府県への寄付金は自動的に判別できるけどね。

(東京都と洲本市・都農町以外は全て対象なわけだし)

日本赤十字社の受領証はどうせPDFでダウンロードするのだし、

同じ情報をXMLでも用意してくれれば助かるのはあるんだけどね。


申告前のチェックで寄付金の条例指定状況の入力がミスしているのに気づき、

危ない危ないと思って修正した程度で、もう慣れたもんですね。

あと、振込先の入力もいらなくなったんですよね。

公金受取口座を使うとしたらそれで済むからである。

この公金受取口座というのも過去の所得税の還付に使った口座なわけで、

実態としては前回のデータを使うに近いのだが、こういうデータを行政機関で保持するようになったのは大きな変化ではある。

ゲーム内のラウンドアバウト

Cities:Skylines2ではラウンドアバウトがシステム的に取り込まれている。

貨物駅周辺の交通をさばくのに効果があるのではと導入してみたが、

それなりによくできたシステムだなと思った。


日本の法令では2014年に環状交差点の制度ができた。

環状交差点の入口に環状交差点標識をつけることにより、

左回り、環道優先、環道内徐行などの効果が得られることとなった。

従来は環道優先というのが明らかではなかったので、

ロータリー交差点の入口には止まれ標識を付けていたが、

環道優先が明らかになる制度ができたことで 止まれ標識を外すのが一般的になった。

すなわち他の車・歩行者がなければ停止せずに環状交差点を通過できると。


Cities:Skylines2では交差点を作ってから、ラウンドアバウトの中央島のパーツを重ねると、

その交差点がラウンドアバウトの交差点になるという仕組みを取っている。

てっきりラウンドアバウトの交差点を置いてから道路を接続すると思ったのだが、

そうではなく交差点の拡張としてラウンドアバウトが存在すると。

当然、単なる十字路に比べて大きいので、既設の交差点に重ねると周辺の建物に影響があるが。


さすがシステム上取り込まれていることもあり、環道優先は徹底されているようだった。

日本のラウンドアバウトは環道内は1車線しか想定されていないが、

ゲーム内では環道内に3車線ぐらいあるのも普通である。

ただ、それがうまくいっているのかというと微妙なところはあるが。

このゲームはとにかく右折が下手なのでラウンドアバウトはある程度マシだが、

やはり交通量が増えてくると苦しいのは現実のラウンドアバウトと同じ。


ただ、一番ダメだったのは環道から出られないという問題で、

これはラウンドアバウトというより接続道路の問題である。

環道優先が徹底されていることの裏返しだが、それで交差点全部潰れるのもひどい話。

それ以外の問題としては環道内の車の流れが途切れず、ある向きからは環道に入れないと言う問題。

これはもう立体交差以外の抜本的な解決はないでしょうね。

平面交差の限界を超えているということなのだし。

横断歩行者に妨害されて進めないというのは信号制御でなければどんな交差点でも起きる問題か。


現実世界だと信号制御が賢いのでそっちの方が処理能力が高いのが定説だが、

Cities:Skylinesの世界では信号制御が下手なので、ラウンドアバウトの方がマシという面はかなりある。

ただ、立体交差化には勝てないというのが実情ですかね。

このレベルの交差点で立体交差化しないとダメなのかと絶望するけど。

立体交差化したら、それはそれで車線変更が下手で困るけど。


で、このゲームはどうにも無駄な走り方をする車が多くて、

あるインターチェンジが改善を重ねても糞詰まりのところがあり、

なんでこっち方向に行く車がこんなに多いんだと調べてみると、

なんでもない片側1車線道路に向かって転回していたのである。

幹線道路はほとんどが一方通行道路というのもあるのかもしれないが、

このゲーム、中央分離帯がないところでは好き勝手に転回するのである。

どうも高速道路を走ってきて、インターチェンジに入り、接続道路に出たら、

片側1車線道路になった途端に転回してインターチェンジに戻るみたいな動きをしていたと。

高速道路の出口をラウンドアバウトで処理したところでもこれが発生して、

ラウンドアバウトを1周回る車が続出し、こうなると他の方向から環道に入れなくなってしまう。


普通はインターチェンジで来た向きに戻る経路は用意しないけれど、

そういうルートを用意しておかないと他への被害が甚大ということで、

わざとそういう穴を用意しておくというのが対策になる。

ただ、そうするとインターチェンジ内を意味不明な走り方をする車が出るし、

それもそれで考え物なんですけどね。


最近新しいパッチが出たようで、死亡率の適正化が行われたらしい。

死者数が多すぎると思っていたので減るのかと想ったらその逆で、

死者数が激増して火葬が間に合わない状態になってしまった。

健康度が低いわけではなさそうだし、一体どういう状況なのか。

人口32万人で火葬場が5つあっても全然回ってない状態で、どうすると。

(パッチ前は火葬場3つで回していた)

火葬が間に合わないことが幸福度に大きな影響を及ぼしてるようには見えないので、

のらりくらりとやっているが、なかなかひどい見た目である。


人口20万人を超えたあたりからいろいろシステムが崩壊している気がするが、

先のパッチで労働者人口が増えるというのもあり、

人手不足問題が解消、一転職場不足になるという状況もあり、

そうなるとそれなりに面白さが増した面もある。

シリアル通信の上限は?

ふと気になったことがあって、マイコンのデバッグで使うUART通信、

評価ボードだとUSB-UARTブリッジICが搭載されていて接続できたり、

あるいはRS-232Cに変換してPCと接続したり……

このときよく使われる通信速度として115200bpsというのがあるが、なんでこのスピードなんでしょうね?


そもそもUARTというのは調歩同期式シリアル通信の代表的なもので、

調歩同期式というのは信号線1本で通信を完結できる仕組みである。

一般的には送信・受信を分けて全二重にすることが多いが、それでも2本である。

SPI通信だとクロック・チップセレクト信号も伝達することが通常だが、

UARTではスタートビットの送信で通信開始を示し、

それを合図に取り決めたボーレートで順番にデータをやりとりして、

最後にストップビットをやりとりしたら1byte送信完了となっている。


UART通信を正しくやる上で肝心なのが時間精度である。

例えば9600bpsで通信する場合、104.2us周期で送信側は信号を切替、受信側はサンプリングしなければならない。

スタートビットからストップビットまでの間に1bitズレると通信に失敗する。

高速になるほど、これがシビアになるので難しい?


とはいえ、その上限が115200bpsとも思えないところはある。

確かにあるシステムでは同じ基板の上に乗ったマイコン同士が1MbpsのUART通信をしている。

なぜUARTなのかというと、この間に絶縁素子があるからである。

信号線1本(往復で2本)で伝達できるというのは絶縁という点でも有利である。

UARTというのはシンプルな方式なので、それ自体に上限はなさそうで、

問題は経路とインターフェースということになろうかと思う。

さっきの例だと絶縁素子のスピードで決まる部分が多いかと思う。

あるいはマイコンのUART機能はクロック周波数の8分周が最速とか決められてるので、

そういうところで最高速度が決まるということである。


通信相手がPCの場合に問題となりそうなのは、RS-232Cという伝送経路と、

USB-UARTブリッジICの性能というところが問題ではないかと思う。

今どきPC自体にRS-232Cが搭載されているということはそうそうなくて、

一般的にはUSB接続のRS-232Cインターフェースと組み合わせて使うが、

その内部にはUSB-UARTブリッジICが搭載されているのが通常である。

それをRS-232Cで引き出した先におくか、評価ボード上に置くかの違いである。


まず、RS-232Cの最高速度だが、規定上は20kbpsとなっているらしい。

この範囲内に入るボーレートでよく使われるのが9600bpsと19200bpsだが……

明らかにこれは実態に合っていなくてRS-232Cはもっと高速な通信で使われることは多い。

無難な数字として9600bpsとか19200bpsが使われることはあるが。

現実的な上限は150~250kbpsぐらいの範囲にあることが多いようだ。

ある基板に搭載されていたRS-232Cのドライバ/レシーバICではMaximum Data Rateは150kbps(min.)となっていた。

このICを介して行うRS-232Cの通信は150kbpsが上限になるということで、

冒頭に書いた115200bpsはその上限に近い数字である。

というか115200bpsの通信は通せる仕様ということでこうしたんじゃないか。


もう1つの要素としてはUSB-UARTブリッジICの対応速度がある。

1Mbpsぐらいは対応しているものが多いようである。

もう少し速くて2Mbpsとか3Mbpsとか対応したものもあるようだけど。

基板上で完結する通信ならば少なくとも1Mbpsぐらいは対応できるとみられるので、

USB-UARTブリッジICを基板上に置けばそのあたりが現実的な上限なのだろう。


というわけで115200bpsというのは現代的なシステムではほぼ対応できるボーレートで比較的速いものとして選ばれたのではないかと思う。

RS-232Cを通すとなると、さらに倍速の230400bpsが通るか通らないかというところ。

堅いのは115200bpsまでということなんだろう。

ただ、UARTという通信方式そのものは1Mbps程度までは対応可能で、

インターフェースや通信経路をよくよく精査すればより高速化は可能かもしれないと。


なんでこんな話を書いたかというと10MbyteぐらいあるデータをROMに書くのに、

マイコンにUARTで送って書き込んでもらうことを考えたのだが、

10Mbyteのデータを115200bpsで送ることを考えると、

UARTで1byte送るにはスタートビット+8bit+ストップビット=10bit送る必要があるので、

所要時間は 10×106×10/115200=868sと求まる。

868秒と言われてもピンとこないが、60で割ると14.5分である。

データ送信プロトコル(例えばYMODEM)のオーバーヘッドなど加味せずにこれだけかかるのである。


で、速くする余地はあるのかと考えたのだが、

まず最初に考えたのはデータ圧縮、ただ、すでに圧縮されているのか効果が見いだせなかった。

効果があればzlibとか組み込んでDeflateしたデータを送るとか考えたけど。

となると、通信速度自体を上げたいと調べたがRS-232Cを介する場合はこれが現実的な上限であると。

1Mbpsまで速くできれば100sだから、2分ぐらいで送信できる計算で、

これだとそんなに悪くない気がするが、さすがに15分は遅いなと。

というわけでシリアル通信で送る作戦は手軽でよいと思ったのだが、

こうも遅いとあまりよい方法ではないと思った。

他の手段がなければ15分かかっても仕方ないですけど。


結論から言えば、以前紹介したICEからプログラムでは無いものを書く方式が速かった。

ICEからプログラムでは無いものを書く

書き込み先のROMはマイコンのプログラムを格納するROMではなかったが、

マイコンには接続されているので、同じような書き込み方をすることはできた。

マイコンのデバッグインターフェースの速度次第だとは思うのだが、

一般的に考えればUARTよりは速いわけで、データ転送だけ考えれば速い。

あとはオーバーヘッドなど総合的に見てどうかという話ではあるけど、

数分で書き込み完了できたので、この方法がよいと思った。

ただ、ICEで接続できる場合に限られるので、やはりシリアル通信で書き込みたい話もあるかもしれない。

Cでレジスタを使ってやらかしてる

コンパイラのバージョンを変えたら正しく動かないという話があり、

なんのこっちゃと調べていたらレジスタやスタックの使い方が変わったことで、

既存のバグ(かそれに近いもの)が露呈した形である。


1つはスタックに確保した配列の範囲外を操作したことによるもので、

なぜこれが見逃されてきたかというのは気になるところだが、

配列サイズを適切に設定すれば解消する問題なので、これはこれでよい。

問題は残り2つで、元々スタックの使用方法に依存する処理と、

どうしてもレジスタ上で処理してほしい処理である。


スタックの使用方法に依存する処理はコンパイル結果に依存することは口伝されていたので、

新しいコンパイル結果に見合った調整を行えば回避できる。

が、そもそもスタックの使用方法に依存する処理というのが問題じゃないかという話で、

そこに依存しないように作っておくべきだったのではというのは……

この問題への僕の考える答えは後で書く。


もう1つのどうしてもレジスタ上で処理したい処理の話だが、

端的に言えばコーディングの問題である。

Cのコーディングでこの変数はレジスタ上に配置することを保証することはできない。

変数宣言時にregisterキーワードを付けるとレジスタ上に配置するよう努めるが、

必ずしもレジスタ上に配置しなくてもよいとされている。

それでコンパイラの独自拡張で変数の配置場所をレジスタに指定することができて、

これを使うことでCでコーディングしながらレジスタ上での処理が保証できるようになっていたが、

問題はこのレジスタ上に配置される変数がグローバル変数扱いだったことである。

グローバル変数といっても当該Cファイルを超えて、extern宣言でアクセスできるわけではないはずだが。


もう1つの問題が使用していたレジスタがスクラッチレジスタではなかったことである。

各アーキテクチャではABI(Application Binary Interface)の取り決めによりレジスタの使い方が決まっている。

32bit版のARMの場合、r0~r3は引数・返り値の受け渡しに使い、r14(lr)は復帰先のアドレスを格納するなど。

で、呼びされた関数で破壊してもよいスクラッチレジスタの規定があり、

r0~r3, r12の5つのレジスタは各関数で退避せず破壊してもよいことになっている。

これ以外のr4~r11, r13(sp), r14(lr)は使用する場合は各関数でスタックなどに退避する必要がある。


どうしてもレジスタ上でやりたい処理をスクラッチレジスタを使ってやっていればよかったのだが、

上を見てもわかるように32bit版のARMの場合、スクラッチレジスタの大半は引数・返り値の受け渡し用でもあり、

そういうレジスタをグローバル変数に割りあてるというのは到底認められないわけである。

そこでこれ以外のレジスタを使っていたのだが、退避させる処理が抜けていたと。

unsigned int reg4; //コンパイラ独自拡張でr4に配置
void something(void){
   unsigned int reg4_keep;
   reg4_keep = reg4;
   //reg4を使った処理
   reg4 = reg4_keep }

こう書いていればよかったのだが、そうなっていなかったのである。

というわけでこういう記述に修正してとりあえず回避できた。

なんでこれで従来問題になってなかったのかが不思議だが。

なお、コンパイル結果を確認するとスクラッチレジスタに退避させているようだった。


最大の失敗はこの処理をアセンブラで書かなかったことではないかと思う。

アセンブラで書いていれば、スクラッチレジスタを使って素直に書けたはずなので。

そもそもスクラッチレジスタとそうでないレジスタについて知識がなかったのでは? というのも気になるけど。

そんな処理があることは以前から知っていた(詳しくコードは見てなかったが)

ただ、ローカル変数をレジスタに割りあてる機能だと勘違いしてて退避処理も入れてくれると思っていたが、

そうではなく自分で退避させる必要があったというのも勘違いなのかもしれないが。


冒頭に書いたスタックの使用方法に依存する処理も、

スタックを使わないようにアセンブラで工夫して書くことはできるわけで、

そうしておけばコンパイル結果に依存しないコードになってたのになと。

もちろんアセンブラで書くことでコーディングのミスを起こしやすいとか、

長期的に見れば移植性の問題などあるにはあるけど、

結局コンパイラのバージョン違いで移植性の問題が起きてるじゃないかと。

最近別の仕事でアセンブラでコーディングせざるを得ないところをいろいろやって、

もうそれアセンブラで書けばと言ってしまいがちなのはある。

難しいことをアセンブラで書いちゃダメですけどね。

いにしえの写真付き切手

先日、知人に封書を送ったら「この切手変わってるね」と言われた。

その昔、祖父が作った「写真付き切手」である。

祖父が亡くなった後、あれこれと持っていた切手を両親が持ち帰ってきて、

その一部をもらったもので、大半は記念切手だが、なんと自作の切手もあったのである。


記念切手としていろいろな柄の切手が発売されることはあるが、

個人・企業がオリジナルの柄の切手を作るというのは制度的に難しいところがある。

一方でオリジナルの切手を作りたいというニーズは存在し、

いろいろ考えた日本郵政公社(当時)は2003年に「写真付き切手」のサービスを始めた。

プリクラ感覚でオリジナル切手シートを印刷 (Internet Watch)

あらかじめ決められた柄の切手の下に提出した写真が印刷されていると。

シール切手になっていて、切手と写真が一緒に貼れるようになっている。

(切手と写真の間にはミシン目が入っているが、切り離す目的ではない)


ただ、いかにも切手と写真という感は強く、2006年に「フレーム切手」のサービスが開始、

額縁状の切手の中に写真などが入っているという形になっている。

切手と写真の間にはミシン目が入っているが、切り離しを目的としたものではない。

これにより一見するとオリジナルの柄の切手を作れているように見える。

実際にはフレーム部分(柄は既製)が切手であって、その内側にある写真は制度上の切手ではないが。

なお、フレーム切手には額縁状のものだけでなく、写真の下に帯状に付くものも存在する。

従来の写真付き切手は切手が上、写真が下だったのが入れ替わったものとも言える。

ただ、切手部分のサイズが大幅に縮小され、写真がドンと目立つ形にはなっている。


写真付き切手の頃からそうなのだが、日本郵便自身が作ったフレーム切手もある。

例えば、オリンピックのメダリストが刷り込まれたフレーム切手がそうで、メダル獲得の数日後に早々発売されている。

記念切手の制作には時間がかかるが、フレーム切手ならすぐに作れるわけである。

他にもいろいろなコンテンツのフレーム切手が発売されており、

以前にコミックマーケットに日本郵便が出展していた話を紹介している。

ファンレターから手紙文化を根付かせる


ところで写真付き切手にしても、フレーム切手にしてもそうなのだが、

実用すると消印が写真部分にかかることがある。

昔の写真付き切手はそれを見越したが切手部分がかなり縦長で、

普通に消印が押されれば写真にはかからないようにしていたんだと思う。

ところでこのフレーム切手は額面80円なのだが、現在の郵便料金には30円足りない。

以前、30円切手(キタキツネ)を入手していたので、これを上に貼って、縦に2枚の切手を並ぶようにした。

こうなると機械で消印が押せなかったか、手押しの消印が押されていた。

「東京北部」の手押しの消印とかなかなか狙って押せるものではないが。

2枚の切手の間を狙って1個押されていて、これで両方潰れているのだが、

勢い余ったか、切手と勘違いしたか、写真のど真ん中に消印がもう1つ押されていた。

あーあ、という感じである。


写真付き切手はできるだけ消印がかからないようにという配慮もあったが、

現在のフレーム切手こそ消印がかからないのは難しいのではないかと思う。

郵便局の窓口で特に指示すれば写真にかからないように押してくれるだろうけど。

写真付き切手・フレーム切手の切手と写真の境目にミシン目があると書いたのはそのためで、

消印が切手部分のどこかにかかっていればよいので、そこを区別するための境界線である。


この写真付き切手の使い道というのはわりと困るもので、

せっかく高いお金出して作ったオリジナルの切手なのだから、

単に額面があればいいような用途で使うにはもったいなくて、

なにか祖父に縁がある人への手紙で使えればと思っていた。

その中ではわりとふさわしい人に送ったつもりだったが「何これ?」みたいに言われるとはまさか。

現在使おうとするとどうしても不足額があるのが煩わしいが、ふさわしい用途では消化していきたい。