無断でゆうパケットに変更していいのか

先日、発売まもない雑誌を中古でメルカリで購入した。

「即日発送」と書いてあり、大阪府から「らくらくメルカリ便」とある。

大阪府~東京都はゆうパケットだと翌々日になることも多いのだが、

ネコポスなら翌日着で、注文したのが昼頃なら当日便に乗る可能性もまぁある。

そんな期待も持って注文した。明日着は過度な期待だとは思ってたけど。


ただ、注文した日のうちには発送通知が来なかった。

翌日、発送通知が来たのだが、発送手段がゆうパケットになっていた。

すなわち らくらくメルカリ便→ゆうゆうメルカリ便 に変更したということである。

発送場所は郵便局、窓口しかない郵便局だから追跡情報の登録が遅れたわけではないだろう。

というわけで想定とかなり異なる発送だった。

発送翌日、すなわち注文翌々日の到着なので十分早いんだけどね。


ネコポス→ゆうパケットの変更と見て、心当たりはあった。

ネコポスの寸法規定は厳しい

この雑誌、変形判で横幅がネコポスの規定を超過してしまうのである。

角2封筒には入るけど、ネコポスの寸法を満たすところまで折れないと。

メルカリの匿名配送の料金設定の都合、ネコポスを発送手段に選ぶ人は多いが、

この寸法規定の厳しさというのを意識して選ぶのは面倒である。

僕は2022年6月の料金改定時以降、多くはクリックポストを使用している。

メルカリの送料が上がるのは経営難だから?

安いというのはあるけど、寸法規定で悩まなくてよいのも理由である。

(まとめ売りのときに1kgの重量制限を意識することはある)


で、取引開始後の発送方法の変更は認められてはいるのだが、

当然のことながら取引相手の承諾を得て変更するべきである。

重量制限がゆるくて助かった

これはメルカリじゃなくてヤフオクの話なんですけど。

匿名配送のゆうパケットから承諾を得てレターパックライトに変更した話。

元が匿名配送なので住所を教えてもらった上で変更をしている。


メルカリでは匿名配送同士の変更をすることもできる。

ネコポス と ゆうパケット の差を気にする人は少ないだろうから、

決済後に寸法を満たさないことに気づいたので変更したが、

この変更で承諾を得る必要があるという意識はなかったのだろう。

「即日発送」が守られなかったのも急遽ゆうパケットに変更した影響かも。

これも一報あってもよかったと思うのだが。


このあたり煩雑に思ったか、なんでも発送方法「未定」で出品する人もいる。

問題はこの商品が6000円ほどと高価で、発送方法が「未定」で登録されていたこと。

というわけで質問したところ、郵便局(ゆうゆうメルカリ便)かヤマト(らくらくメルカリ便)が決めていないということだった。

ああ、なるほど。それで「未定」だったんですか。

本当はどちらか適当に決めてくれた方がいいのだが、理由は理解できるのでそのまま購入手続きをした。

(未定は匿名配送にはならない)

ただ、この場合は匿名配送にならないという欠点もある。


ところでヤマト運輸は2024年度末までにネコポスの提供をやめると発表している。

現在は発送元の地域ごとに クロネコDM便・ネコポス から クロネコゆうメール・クロネコゆうパケット への切替をしているところである。

ただし、メルカリなどの個人間取引のネコポスは全国的に継続している。

具体的にどのような対応になるかはまだ発表されていない。

他のプラットフォームと比較してもメルカリは特にネコポス利用者が多い。

ヤマト運輸にとってもメルカリのネコポスが一掃されないと楽にならないだろうし。

一体どうなるんでしょうね。僕はもうネコポス使わないだろうけど。

wfi命令で割り込みを待つ意味

今まであまり使うことがなかったのがマイコンのスリープ機能である。

低消費電力化が求められるシステムなら当然使うんだろうけど。

割り込みが来るまで処理を止めるという話ですね。


で、ARMの場合、wfi命令というのが用意されている。

この命令を実行すれば割り込みが来るまでお休みになる。

while(1){
   if(flag==0){
     __asm("wfi");
   }
   if(flag==1){
    ...

割り込み処理でflag変数に何か入るまでループで待つというのを、

flag変数が0ならばwfi命令を実行して、割り込みが入るまでスリープ状体でお休みと。

wfi命令とif(flag==1)の間で割り込みが実行されることを期待しているわけだ。


でも、if(flag==0)とwfi命令の間に割り込みが入ったらどうするのだろう?

ここでは省略したのだが、実際のコードではこの間にUARTの受信割り込みを有効化するための処理が入っている。

フラグを見て直後にwfi命令を実行していると言い切れない部分もある。

そんなわけでwfi命令の使用例を調べてみると、こんなアセンブラコードが見つかった。

cpsid i /* 割り込みマスク */
mov r4, #0
msr basepri, r4 /* 全割り込み許可 */ wfi
cpsie i /* 割り込み受付 */

wfi命令は割り込み待ちの命令だが、その直前に割り込みマスクをして、

それでwfiを出たら割り込み受付をするという書き方である。


これを見てもわかるのだが、wfi命令というのは割り込み待ちが発生した時点で解除される。

なので割り込みマスク状態で動かしてもOKなんですね。

むしろそのように書くことでwfi命令に入るまでに割り込みが消化されてしまうリスクがなくなる。

というわけで、さっきのflag==0ならwfiで割り込み待ちというのは、

while(1){
   __asm("cpsid i");
   if(flag==0){
     __asm("wfi");
   }
   __asm("cpsie i");
   if(flag==1){
    ...

と書くとよい。

こうすればif(flag==0)とwfi命令の間に割り込まれる心配がなくなる。


このあたり厳密にやらなくてもだいたい動いてしまうんですけどね。

さっきのアセンブラコードの場合、wfi命令の前に割り込み優先度の操作をしている。

このため割り込み優先度の操作をした途端に割り込まれる可能性がある。

なので、一旦割り込み禁止にして、優先度を変えているんですね。

で、優先度を変えたことで割り込み待ちになればwfi命令は即抜けになる。

割り込みマスクを解除したときに割り込み処理が走るというわけ。


このコードを見る前から割り込みマスク中でもwfi命令から抜けるらしい、

という話は見ていて、一体何のためにそうなってるんだろうと思ったら、

こういう使い方をするためだったんですね。

もちろん割り込み有効状態でwfi命令を使っても、それはそれで動くのだが、

割り込みマスク状態で使って、wfi命令を抜けたら割り込みマスクを解除するという動きの方がより正確な動きのようである。


あと、これは特に関係ないが、wfi命令を検索するとwfe命令のことがひっかかる。

割り込みが発生するまでスリープするという目的ではwfi命令を使うのだが、

wfe命令というのは他のコアでsev命令が実行されるまで待つことを目的としている。

wfeは”Wait For Event”、sevは”Set Event”で一対の命令である。

ある変数が書き換わるまでポーリングするという処理をするのに、

wfe命令で待って、他コアで書き換えたらsev命令を実行するような使い方をするらしい。

    sevl
1:  wfe
    ldr r0, [r1]
    cbz r0, 1b

sevl命令は他コアでsev命令が実行されてなくても、次のwfe命令は抜けるという意味になる。

(sevlは”Set Event Locally”の意味で、自コアだけイベントをセットする意味)

1回はr1レジスタのアドレスに格納されたフラグをチェックして、

そのフラグが0ならばwfe命令に戻って待つという記述である。

で、この間に割り込みが入るか、他コアでsev命令が実行されればwfe命令を抜けると。

割り込みが入るまで待つという部分はwfi命令とも共通するのだが、使用目的が異なる。

他コアからのフラグをポーリングしている間でも割り込みは入らないと困るから抜けるだけである。

これは使わなさそうな感じがするが、そういうのあるという余談である。

凝固因子製剤を輸出する意味

ラブラッドで成分献血の予約をしようとしたらこんな案内が出ていた。

血漿分画製剤の海外輸出に伴う献血同意内容の追加について (日本赤十字社)

国内自給に支障が生じない範囲で血漿分画製剤を輸出していることを同意書に記載するという内容。

すでに輸出は行われていて、具体的には凝固因子製剤の世界血友病連盟への寄付である。

2023年度 血液凝固第Ⅷ因子製剤の世界血友病連盟への寄付について (日本血液製剤機構)


そもそも血漿分画製剤について。

あの手この手で血漿が欲しい

血漿分画製剤は血漿から必要な成分を抽出した薬である。

血漿を成分ごとに分けて使うことで血液の有効利用にもつながっている。

血漿分画製剤は大きく分けると アルブミン製剤・免疫グロブリン製剤・凝固因子製剤・アンチトロンビン製剤・組織接着剤 とある。

後ろ3つは血漿中の血液凝固に関わる成分を集めたものである。

現在、血漿成分献血の推進をしているのは、主に免疫グロブリン製剤の需要に対応したものである。

一方、主な凝固因子製剤、第VIII因子と第IX因子については血漿由来は国内自給率100%である。


凝固因子製剤は血友病の治療に使われる。

第VIII因子が不足するものを血友病A、第IX因子が不足するものを血友病Bという。

これを補充することで血液がちゃんと固まるようにするという意図である。

ただ、最近は血漿由来の製剤よりも遺伝子組み換え製剤が使われることが多いのだという。

「血友病」の治療、新たな薬が続々と 患者・家族のQOL改善に期待 (朝日新聞デジタル)

血漿由来に比べて効果が長く続くものや、凝固因子を異物として排除してしまうインヒビターのある患者でも効果を得やすいものが出ている。

そのため血漿由来の製剤が選ばれにくくなっているということらしい。


もちろん患者の負担軽減や治療効果向上はメリットがあるし、

献血によらず安定供給できることもよいことである。

ただ、遺伝子組み換え製剤は製造しているメーカーが限られるので、

何らかの理由で供給が滞ったときに、血漿由来製剤で代替する必要があり、

それで実際に血漿由来製剤を増産したことも過去にはあるという。

血漿由来の製剤が完全に代替出来ればそれに越したことはないのだが、

今のところは血漿由来の凝固因子製剤も必要と考えられているわけである。


というわけで献血由来の凝固因子製剤を途上国向けに寄付することには、

国際貢献というのもあるだろうけど、いざというとき国内で作れるようにという意図もありそう。

平時の国内自給という点では全く問題ないわけですからね。


というわけで、やはり免疫グロブリン製剤の安定供給が課題ではあって、

近年の需要増もあって、まだ足りていない状況ですね。

世界的にも需要増らしく、血漿成分献血への期待は大きいわけである。

フェブラリーステークスの面々

年2回あるJRAのダートG1の1つ、フェブラリーステークス、

このレース自体は昨年までと特に変わらないのだが、今年から川崎記念が4月上旬に移設され、

その影響かわからないけど、不思議な面々が揃った気がする。


そもそも昨年のフェブラリーステークスもなかなかの顔ぶれだった。

フェブラリーステークスの珍客

サウジカップが同時期に行われるようになり有力馬が流出しているという事情がある。

2021年・2022年とフェブラリーステークスを連覇したカフェファラオが、

2023年はサウジカップを選び3着になり、類似性を示した形である。

今年も昨年のフェブラリーステークス優勝馬、レモンポップはサウジカップを選んでいる。

サウジカップは高額賞金ゆえ選定されるのが難しいとは書いたものの、

アメリカ勢の興味も落ちたか、今年は日本から5頭選定されている状況である。


川崎記念は歴史的にもドバイワールドカップの前哨戦として使われてきたが、

移設によりドバイワールドカップとちょうど同時期になった。

そのためドバイワールドカップデーの前哨戦としてフェブラリーステークスを使う馬が増えた。

これが昨年までの変化として大きいのかなと思った。

具体的にはウィルソンテソーロがドバイワールドカップへの転戦を、

イグナイターがドバイゴールデンシャヒーンへの転戦を意図しての参戦だった。

(ドバイゴールドシャヒーンへの転戦は昨年にレモンポップもやっているが)


地方からの参戦も3頭いた。

昨年も参戦して5着のスピーディキック、昨年の南関東三冠のミックファイア、

そしてJBCクラシック優勝・南部杯2着のイグナイターである。

(上記にも書いた通り、イグナイターはドバイへの転戦も意図している)

JRAのダートG1は地方所属馬も賞金順で普通に参戦できるレースである。

とはいえ同時期に地方でよきレースがあればあえてJRAのレースを選ぶ理由は少ない。

が、川崎記念の移設で同時期に地方のG1級レースが1つ減ったわけですよね。

今回の面々と川崎記念の移設との関係は明確ではないが、今後はこういう事例も増えるのだろう。


そして芝からの転戦である。これは昔からあったかな。

今年はシャンパンカラー、カラテ、ガイアフォースが前走芝である。

このうちガイアフォースは賞金順だと除外になるところ、レーティング順で出走できたという経緯がある。

どういうこっちゃと思うわけだが、昨年の安田記念4着で117ポンドを獲得していた。

この数字で出走したのだが、芝の数字がそのまま使えるのか? とは思う。

フェブラリーステークス(GⅠ)に特別登録している日本馬のレーティング順位 (JRA)

これを見るとガイアフォースは115ポンドで登録馬中4位として記載されている。

芝の実績から2ポンド引いた数字で、かつ115ポンドの馬の中では最下位にしても、

レーティング順での出走が認められる上位5頭に入ったわけである。

基本的には芝からの転戦への期待度が薄いのはそうだけど、

2022年に昨年の桜花賞を優勝したソダシが3着に入ったり、稀に活躍するのもいるし……

でも、やっぱりいきなりG1じゃなくて、ダートで前哨戦を挟むべきでは? という意見もある。


そんなこんなで出走馬をかき集めた感じの強いフェブラリーステークスだが、

結果は大荒れ、11番人気のペプチドナイルが優勝。

重賞ではあまり結果が出てなかったのにいきなりG1を勝って困惑させる。

2着はガイアフォース、芝のレーティングで出走して2着なら立派か。

3着は接戦だったが13番人気のセキフウということで決着。

かくして3連単で153万馬券という、かなりすさまじい結果になった。

地方からの3頭はミックファイアが7着で賞金(出走奨励金)が出たが、

イグナイターは11着、スピーディキックは13着とタダ走りである。

(JRA所属でOPクラスなら11着以下でも特別出走奨励金が出る)


大荒れのフェブラリーステークスについて「群雄割拠だね」と言う人がいて、

それは確かにそうなのかもしれない。

有力馬はサウジカップデーに向かってしまったというのはあるけど、

それで空いたからこそいろいろな馬が集まったのはその通りである。

JRA所属馬にとっては地方開催のダートグレード競走は出走枠が限られる。

比較的出走しやすいJRAのダート重賞だからこその面々というのはあった。


さて、来週はサウジカップデーである。

サラブレッドの6レースに計22頭の日本調教馬が向かっている。

えらく多いがダート・芝双方に有力馬を送り込めるのは日本ぐらいという事情もある。

今年からサウジカップが海外馬券の発売対象レースに加わった。

サウジカップを筆頭にそれ自体が高額賞金レースというのはあるけど、

ドバイワールドカップデーの前哨戦として注目されている面はある。

果たしてどんな結果が待っているのだろうか。

受取可能駅の理解しにくさ

滋賀から横浜に出かけるのに、新幹線をどうやって予約しようと言ってる人がいて、

e5489で予約して帰りに横浜で受け取れるかわからないという話だった。

ああ、なるほど。確かにこれはちょっと難しい問題だ。


JR東海も主に在来線特急の予約システムとしてe5489を導入している。

なので、JR東海の駅ではJR東海区間を含むe5489の受取ができる。

これは東海道新幹線の駅でもよいが、厳密にJR東海の駅に限られる。

すなわち横浜市内では新横浜駅(その中でもJR東海の券売機・窓口)に限られる。

横浜~滋賀県内の乗車券は通常、横浜市内発着で出る。

すなわち本来は横浜駅とか桜木町から使えるきっぷを新横浜でしか受け取れないことになる。

なので乗車券は往復とも出発前に受取、特急券だけ新横浜での乗換時に受け取る。

これならばe5489でもおそらく問題なく往復利用できる。


ただ、この話をしていて、新幹線と在来線で会社が違う区間が難しいと思った。

東海道新幹線は全線がJR東海の管轄だが、まずそれがよく理解できていない。

東京・品川・新横浜・小田原・熱海は周りはJR東日本、新大阪・京都・米原は周りはJR西日本である。

当然のことながら窓口できっぷを買うときはこれらの会社の窓口で買うことが多い。

桜井駅で名古屋~東京方面の新幹線のきっぷを買えるのは当然とは言えない面もある。

(奈良県内から近鉄で名古屋まで行く人がこういう買い方をすることがあるらしい)

しかし、新横浜からの新幹線のきっぷを桜木町で受け取ることに制約があるのは、なかなか理解しにくい話だと思う。


以前、JR各社のインターネット予約システムの話をいろいろ書いた。

JR各社の予約システムは難しい

JR東日本・西日本・九州がそれぞれ在来線・新幹線の予約システムを持っていて、

これと東海道・山陽・九州新幹線専用のエクスプレス予約(東海・西日本・九州3社共同)があると。

会社またぎの列車も存在するため、この点も概ね考慮はされているが、

あまり考えずに予約すると不便な状況に陥ることは現在もある。


東海道・山陽新幹線は最長で東京~博多を走っている。

これ自体はJR東海とJR西日本の2社またぎだが、周りはJR東日本とJR九州である。

JR東日本の えきねっと で予約するとJR西日本・九州の駅では受け取れない。

JR九州ネット予約を使うとJR東海・東日本の駅では受け取れない。

現在はエクスプレス予約にJR九州が参加するようになり、

東京都区内・横浜市内・小田原・熱海のJR東日本の券売機での受取に対応し、

エクスプレス予約を使った場合はあまり不便を感じないで済む。


名古屋~松本・長野を結ぶ特急しなの、東海・東日本の2社またぎである。

以前は乗車直前にきっぷを受け取るには往復で予約システムを使い分ける必要があった。

2019年からJR東海では在来線特急の予約システムとしてe5489を導入した。

なので東海管内では乗車直前にe5489で予約したきっぷを受け取れる。

これはよいがe5489はJR東日本の駅では基本的に受け取れない。

(長野駅は北陸新幹線のためe5489対応しているが以前はJR東海区間を含むものは受け取れなかった、現在は解消済み)

一方の えきねっと はJR東日本では当然よいが、東海の駅では受け取れない。

このため往復で予約システムを使い分ける人がいたが、

2022年にJR東海の駅の券売機で えきねっと の受取に対応したことで、

しなの号は往復とも えきねっと で予約すれば乗車直前に受け取れるようになった。


e5489の受取可能駅にまつわる問題がサンライズ瀬戸・出雲である。

寝台車に対応した予約システムがe5489のみという事情がある。

ただJR東日本の駅でe5489が受け取れるのは北陸新幹線絡みのみ。

JR東海でe5489に対応するようになってからは、東京・熱海についてはJR東海で受取ができるようになった。

問題は横浜駅である。新横浜駅に行けばJR東海の窓口・券売機で受け取れるが、横浜駅では対応できない。

冒頭に書いた問題に近いのだが、そもそもe5489しか対応できないことが問題を大きくしている。


最後に米原駅でしらさぎ号と東海道新幹線を乗り継ぐ場合について。

今年3月に北陸新幹線が敦賀が到達してからは、米原~敦賀で新幹線同士を結ぶ役割を持つ。

乗継割引廃止もあって、エクスプレス予約と連携した乗継きっぷをe5489で扱うようになる。

これ自体はそういうものかと思ったが、米原~北陸方面はJR西日本完結、

そのためJR東海のe5489受取対応駅での受取ができないのだという。

理屈上はそうなるのかもしれないけど、米原駅の乗換ってけっこうタイトだぞと。


実態としては 名古屋~米原~北陸方面 のような利用が想定されるわけで、

それは名古屋で乗車前に一括して受け取れるべきだろうと思う。

これを契機にJR東海でのe5489受取条件の緩和を検討するべきだったのでは?

あと、なんでチケットレスじゃないんだろうかとは思った。

「北陸乗継チケットレス」という在来線は特急券のみチケットレス(乗車券はICカード利用を想定)、

新幹線はICカードに紐付けて利用できる乗車券一体型のチケットレスという、

そういう組み合わせの商品を用意してるんですよね。

EX商品なんてICカード持ってるの前提なんだし、それと同じでよかったのでは?


昔に比べればだいぶよくなったけどね。でも不便なことはある。

わりとJR東海絡みで問題が多い気がするが、サンライズ瀬戸・出雲の件はJR東海のe5489導入で緩和されたという側面もある。

JR東日本も北陸新幹線対応でe5489入れているけど、拡大した方がいいのでは?

JR西日本のえきねっと対応は北陸エリア限りだが、こちらは実態として問題は少ないかもしれない。

ただ、えきねっとが山陽新幹線停車駅でも対応すれば選択肢が広がるとは思う。

(現在は東海区間を含む えきねっと の予約は西日本管内では受け取れない制限があるので、これが解除されるのが前提だが)


こういうのを考えないといけない時点でダメだと言われればそうだけど。

そして、新幹線絡みは錯誤が起きやすいことも理解しておくべきだなと思った。

極地法の行きと帰りの違いゆえ

先日、エベレスト登山のトイレの話を話を書いた。

山のトイレをどうするか

最後にこう言う話を書いた。

ベースキャンプより先でも滞在期間が長いのが原因の1つだろう。

確かにそれはそうなのだが、極地法の特性というところもあるらしい。


極地法というのはかつての南極や北極の探索手法に由来する呼び名である。

ベースキャンプから物資を運び込んで前進キャンプを設営し、

その前進キャンプを拠点に探索を進めて、前進した先にキャンプを設営し……

という形で探索を進めていくという手法である。

もっとも今どきのエベレスト登山というのは定型化されていて、

事前にルート工作や設営などした上で、登山者がこれらを使うという形になっているのが実情だが。


この手法でしばしば問題となるのがゴミのことである。

単純に考えれば登山時に持っていったものを下山時も持って帰ればよいが、

極地法では前進時の運搬は何回にも分けて行うことができる。

前進時にはルート工作や高所順応を時間をかけて行うので時間がかかる。

しかし、山頂に到達すれば、ベースキャンプまでは片道1回である。

何回にも分けて上げた資材を1回で降ろすのは容易ではない。

このためゴミが残されてしまうことが多いのだという。


片付けまでやって登山完了だという考えもあるかもしれないが、

そのような計画を立てても天候面で実現できない可能性がある。

そうすると結局はゴミが取り残されてしまう。

極地法をとる以上、ゴミ問題を完全に避けるのは難しいのかもしれない。


極地法の対義語はアルパインスタイルというのがあり、

少人数で手早く登山するという、一般的な登山をやるということだな。

しかし、そのためには物資を切り詰め、ルート工作も時間をかけられない。

安全に対する備えができないということで遭難のリスクが高まる。

8000m峰のような厳しい環境でやるのは厳しいなぁと思う。


ところでエベレスト登山はネパール側と中国側それぞれに主要なルートがある。

ネパール側のルートは ルクラ という町に小さな空港があり、ここがスタート地点になることが多い。

ここから徒歩で1週間ぐらいかけてベースキャンプまで行くことになる。

この区間の物資の輸送手段はヤク(牛の仲間)も使われているという。

標高5364mのベースキャンプがヤクを使って物資を輸送できる限界である。

その先には崩落の危険があるアイスフォールがあるので、人が注意深く運ぶしかない。

このアイスフォールはネパール側からの登山の最大の懸念事項だという。


一方の中国側は物資輸送という点ではネパール側よりだいぶよい。

こちらの標高5150mのベースキャンプは自動車が入れる限界地点である。

ヤクで輸送できる限度はさらに先の標高6400m地点である。

ここに置かれるキャンプをアドバンスドベースキャンプ(ABC)と呼ぶそう。

というわけで輸送と言う面では中国側のほうがよさそうである。

これはゴミを運び出す側にとっても有効なのではないかと思う。

もっとも支援体制や難易度を考えるとネパール側の方がよいらしい。


というわけで難しい問題ですね。

地球で最も高いところに行きたいと思う人が多くいるのはそうだろうし、

その中で安全な登山が求められているというのもそうだろうと思う。

そうすると極地法の仕組みが求められることになるが、

この極地法は本質的にゴミ問題を回避しがたいということになる。

登山を諦めてもらえばよいが、それで納得するかって話だよな。

予約してメモリを書き換える

マルチコアの制御を行うプログラムでcmpxchgという関数があった。

この関数でプログラムが停止して、いろいろ面倒なことがあった。

アセンブラで書かれている関数でよくわからないなと思って調べたら、マルチコアのシステム特有の処理らしい。


この関数はメモリ上の値がある値であることを確認したら書き換えるというものである。

Compare and Exchange の略で cmpxchg という名前だったらしい。

で、ARMのA32命令で書くとこんな感じの関数である。

# 引数: r1=ptr, r2=old, r3=new
# 返り値: r0
1:  ldrex   r0, [r1]
    mov     r4, #0
    teq     r0, r2
    strexeq r4, r3, [r1]
    teq     r4, #0
    bne     1b

ldrex命令を実行してアドレスr1の値を取得してr0レジスタに格納する。

ただのロード命令と違うのは、書換の予約をするということである。

r2レジスタには当該アドレスで想定されている値が格納されている。

ldrex命令で取得した値と不一致ならば、書換をせずに終わり。

一致していれば、r3レジスタに格納された値への書換を試みる。

それがstrex命令(eqを付けてr0=r2の場合のみ実行としている)である。

strex命令はアドレスr1の値がldrexでの予約後に他のコアが触っていないか見て、

触っていなければr3への書換を実行してr4に0を格納する。

もし触っていれば書き換えずにr4に1を格納し、その場合はldrexからやり直す。

ちなみに bne命令の分岐先1bというのは上にあるラベル1という意味らしい。

逆に下にあるラベル2は2fと書ける。そういうアセンブラの記法があると。


この方式を Load-Link/Store-Conditional(LL/SC) と呼ぶそうである。

Load-Linkが読み出して予約するというのでldrex命令に相当する。

Store-Conditionalが予約後に書換がない場合に書き込むというのでstrex命令に相当する。

そもそもこのような方法が必要になるのはマルチコアだからである。

シングルコアであれば割り込み禁止にしておけば、他のプログラムに書き換えられることはない。

でも、マルチコアの場合、他のコアが書き換える可能性がある。

打開策はいくつかあるが、LL/SCは予約先への他のコアのアクセスを監視することで解決する方法である。

もしも予約先に他のコアがアクセスしてたら書き換えずにやり直すと。


このcmpxchg関数の使用例として、こんなものがある。

if(cmpxchg(&lottery,0,1)==0){
   something(); }

lotteryの初期値が0であるのが前提だが、

最初に実行したコアが0→1の書換をしてsomething()に書いた処理を実行し、

それ以降に実行したコアはすでに1なので何もしないと。

めったに競合しないとは思うが、もし競合すればcmpxchg関数の中でやり直すことになる。


この方式は予約したアドレスへの他のコアのアクセス有無がわかればよいが、

この仕組みが働く領域と働かない領域があるようで、

その都合でcmpxchg関数でプログラムが停止する問題が起きていた。

他のコアのアクセスを監視するというところに何らかの制約があったよう。

シンプルそうに見えるのだが、意外に難しい仕組みである。

N700系のこだま号専用車

山陽新幹線らしい光景と言えば、こだま号で活躍する500系とレールスター700系である。

なかなか他の新幹線では見ない見た目の車両でこれがユニークだが、

かなりボロいよなとは思う。実際、山陽新幹線でも飛び抜けて古い。

そんな500系について置き換えの計画が出てきたようだ。

山陽新幹線の安全性・快適性の向上 (pdf) (JR西日本)


主にのぞみ号で使われる車両は東海道新幹線と同じ型を導入している。

東海道新幹線で導入が進んでいるN700Sの導入を進めるということである。

これにより余剰になるN700系16両編成を、8両編成に短縮して こだま号専用車に、

500系の6編成中4編成がこれにより置き換えられるという内容だった。

全廃が示されたわけではないものの、500系全廃の日はそう遠くないのだろうと思わせる内容である。


N700系は従来の700系に比べて様々な差がある。

注目されたのは山陽新幹線での300km/h走行と、車体傾斜による速度向上だったが、

他にもいろいろあって、短編成化が容易という特徴もあった。

短編成化が容易という特徴は 山陽・九州新幹線直通用の8両編成で早々生かされた。

また、西九州新幹線ではN700Sの6両編成タイプが使用されている。

台湾高速鉄道にもN700Sベースの12両編成が納入される予定である。

というわけでN700系の16両編成から8両編成への改造は比較的容易とみられる。


ただ、一方で疑問点としてはN700Sを16両編成を購入するよりも、

そもそも8両編成のN700Sを購入した方が安上がりなのでは? ということ。

というのも、N700系の短編成化というのは8両捨てるということである。

N700Sを16両買って、500系8両とN700系8両を捨てるよりは、

N700Sを8両買って500系を8両捨てる方が老朽化対策としては効果的なのでは? と。

のぞみ号へのN700S導入を優先したいという意図がありそうなのだが、

N700とN700Sは車内設備が多少異なるものの、そこまで大した差はなさそう。

700系→N700系のときは車両を統一することで全体のスピードアップができたけど、そういう意図はないでしょう。

となると、のぞみ号でN700系を使い続けても悪くないのでは? とも思う。


ただ、のぞみ号で走らせると走行距離はかさみますからね。

走行距離のことを考えれば適当なタイミングでこだま号専用車にして、

走行距離を抑えながら長く活躍させたいという意図もあるのかもしれない。

実際、500系は新幹線にしては本当に長持ちしている車両である。

今日まで現役でいるのもこだま号専用車になったからこそである。

N700系も長く活躍することになるのだろう。

もっとも16両編成の700系はすでにすべて引退しており、

N700系は山陽新幹線ではこだま号専用車以外ではもっとも古い型式である。


山陽・九州新幹線直通用のN700系を置き換えて、

これをこだま号専用車にするのでは? という観測もありましたけどね。

のぞみ号のN700系をN700Sにしてというのも、これはこれで効果的ということで。

登山道を少しだけ県道から削る

山梨県が富士登山の安全対策のため、登山道の一部を県道から削ったという。

富士山の弾丸登山・混雑解消へ「秘策」 山梨県、道路法の適用外す規制案を2月議会に提案 (産経新聞)

道路法の規定では、登山者数の抑制を目的として通行規制はできない。

道路法46条では道路に危険がある場合か工事の場合に通行禁止にできるとある。

富士山の登山道が冬期に閉鎖されるのも道路が危険だからである。


そもそも富士山の登山道の主要ルートは静岡県道・山梨県道になっている。

静岡県側は下記2路線3ルートが登山口への道路と登山道で構成されている

  • 150 足柄停車場富士公園線: 須走ルート+ふじあざみライン
  • 152 富士公園太郎坊線
    • (新道) 富士宮ルート+富士山スカイライン
    • (旧道) 御殿場ルート

一方の山梨県側なのだが、吉田ルートが1本指定されているのかと思いきや、そうではないのである。

  • 701 富士上吉田線: 吉田口登山道
  • 702 富士精進線: 精進口登山道
  • 707 富士河口湖富士線: 富士スバルライン

このうち実際に山頂に通じているのは701号富士上吉田線のみである。


一般に富士山の吉田ルートと言えば、富士スバルラインで五合目まで往来するルートを指す。

吉田口登山道と吉田ルートの登山道部分は同じものではない。

登山口と登山ルート (富士登山オフィシャルサイト)

黄色の吉田ルートは登山道・下山道で2本引かれているのはともかく、

六合目または五合目で「富士スバルライン五合目」と「吉田口」に分岐している。

この吉田口と書いてある先にずっと進むと北口本宮富士浅間神社がある。

このルートこそが吉田口登山道、伝統的な登山ルートで県道701号線である。

なお全部が登山道ではなく、浅間神社~馬返は車両通行可である。

吉田口六合目または五合目 と 富士スバルラインを結ぶ登山道は吉田口登山道に含まれないのだが、

ここは精進口登山道、精進湖からの登山ルートを利用したものになっている。

精進口登山道は吉田口五合目より下が県道702号線となっている。

全区間が車両通行不可で純然たる登山道である。

一般的な吉田ルートというのは、富士スバルライン(県道707号線)を自動車で走り、

富士スバルライン五合目と吉田口の間で県道702号線を歩き、

吉田口登山道と合流してからは県道701号線を歩くという形だった。


で、山梨県は県道702号線の五合目ロータリー~泉ヶ滝の県道指定を外したわけですね。

これにより県道702号線が吉田口登山道から切り離された形になる。

そして道路ではなくなった登山道は県管理の登山道となる。

この区間の通行を1日4000人に規制、16時~翌2時の通行制限を行い、

さらには富士山保全協力金とは別の通行料(2000円)を徴収するという。

この通行料については山小屋がない下山道の安全対策にも使うという。

下山道も県道701号線には含まれていないので、これも県管理の登山道という形で整理するという。


ここからもわかるように吉田口登山道を歩く場合は規制対象外になる。

登山者が多くなるとは思えないルートなので問題ないのだろうが。

富士スバルラインから登山道に入るところで規制できるとスムーズで、

登山ルートの主要な部分は県道として管理できたほうがよいということなのだろうか。

精進口登山道の県道指定の意味が薄れるが、登山者は極少ないか。


山梨県側について言えばそういうことになるが、懸念は静岡県側である。

山梨県側で規制にかかるなら静岡県側に回ろうとならないか。

静岡県側については山梨県のような対策はできないという。

これは登山道が国有地のため、県道ではなくなると県の施設として管理できないためだという。

現状は様子見ということになるが夜間の通行規制については静岡県側でも実施する話がある。

山梨に続き静岡側も夜間入山制限 富士山の弾丸登山防止 (産経新聞)

ただ、山梨県側ほど強い対策はできないんじゃないか。


ところで富士スバルラインは有料道路だが、当然とは言えない事情がある。

本来、有料道路というのは建設費の回収が終われば無料開放される。

全国路線網の場合は徴収期間を2115年まで延長する計画もあるが、

とはいえ、これも老朽化対策の工事費を回収するという名目がある。

富士スバルラインについては本来は2005年に徴収期間が終わるはずだったが、

路線の特殊性もあって維持管理有料制度に移行している。

有料道路は有料であるうちは通行料から維持費を出すが、

無料開放されれば他の道路と同様に税金で維持することとなる。

しかし、それが不適な場合は維持費のために有料道路を続けることが認められている。

これが維持管理有料制度で富士スバルラインは 関門国道トンネル(1973年~)に次ぐ2例目である。


このあたりの考え方からも道路の通行抑制というのは難しいことがわかる。

基本的には道路というのは広く利用できるものと規定されている。

一方で登山道を道路として管理することで安全対策がやりやすい面もある。

道路である以上は基本的には税金を投じることになるわけだけどね。

このあたりのせめぎ合いから、富士スバルライン~吉田口登山道を結ぶ区間だけを県道から外すということになったのだろう。


以前、宮島訪問税の話を書いたときにも富士山のことに触れてるけど……

宮島訪問税対応のため

基本的には訪問者による超過コストを補うという考えがあるため、

訪問者を抑制するほどに高い税金を徴収するということは認めにくい。

また、税金の場合は公平な徴収が出来るかという問題もある。

沖縄県の離島や宮島は入域手段が船などに限られているので容易である。

現状の富士山保全協力金も静岡県側はルートが分散するため呼びかけが難しく協力率は今ひとつ。


そんな諸々の事情を考えたときに、登山道の一部を県道から外すのがよいとなったんだろうな。

山の公共性という観点で登山道というのは自由に利用できるべきだが、

県管理でそれなりの理由があっての制限ならば問題はないのかなとも思う。

とりあえずは吉田口登山道は規制対象外だし……

通行料も登山道の維持費や環境対策費は登山者が負担するのが相応だろう。

道路と考えると通行料の徴収というのはそぐわないわけだけど、

小中学校の通学路などの生活に密接した道路と登山道では全く違うわけですよね。

ただ、登山者に求めている富士山保全協力金と吉田ルートで徴収する通行料、

役割が重複している部分がある中で合理的な説明ができるのかという疑問はある。

最大の心配事は静岡県側の登山道の混雑かな。大丈夫ですかね?

2つのマイコンを1つにする難しさ

少し前からマイコンについてのあれこれを書いてきたのだが、

これは仕事でとあるシステムを構築するための検討に関連しての話である。

これぐらいなら書いてもいいんじゃないかということで、どんなものを作ろうとしているかという話。


ことはシステムに搭載された2つのマイコンが製造中止になる話から始まる。

けっこう古いマイコンだったんですね。

単純に新しいマイコンに置き換えられればよかったのだが困難な事情もあり、

元々搭載されていたFPGAをマイコン入りのFPGAに置き換えることになった。

FPGAにマイコンの周辺回路を作り込めるのがポイントだったんですね。

で、このマイコン入りFPGAには複数のコアが搭載されているので、

2つのマイコンの役割をコア1つずつ割りあてようとした。


発想としてはありそうな話なのだが、これがそう簡単なことではない。

というのもこの手のマルチコアのプロセッサーはコアを個別にリセット・起動することは想定されていないからである。

使い方の例として、複数のコアを使ってLinuxを立ち上げる例や、

コアの一部をLinux、一部をリアルタイムOSで使う例が書かれているのだが、

外部信号で個別に起動・停止を行うハードウェアの仕組みは備わっていない。


マイコンが変わることでリアルタイムOSも新しいのを買わないといけない。

それで問い合わせたところ、全コアまとめて1つのOSでマネージメントした上で、

タスク群Aはコア1に、タスク群Bはコア2に割り付けて動作させるという構成を提案された。

元々複数のマイコンでやってた仕事を1つのマルチコアシステムにまとめるのはよくある話なんだろう。

タスク群ごとにコアを分けておけば、他方のタスク群の処理時間が増えても影響を受けずに済む。

全コアまとめてOSに渡せば、そこからはOSで対応してくれるし、

コア間の通信はOSの一般的なシステムコールで対応できるのもよい。


ただ……このシステムは元々2つのマイコンに分かれている前提の要素が多すぎた。

個別での起動・停止、個別でのファームウェアアップデートなどがある。

個別の起動・停止をタスクの生成・破棄で代替出来ないか。

個別でのファームウェアアップデートをアプリケーション部のみの差し替えで対応できないか。

1つのOSで全コアをマネージメントする方式でどこまで互換性を保てるか。


一方でコアごとにOSを分けるという構成もあるはずじゃないかと。

Linuxを動かすコアと、リアルタイムOSを動かすコアに分けられるなら、

コアを分けて2つのリアルタイムOSを起動させることはできないか。

これ、起動させるだけならば、そこまで難しいことではない。

問題は個別に起動・停止を行う仕組みである。

ウォームリセットとコールドリセット

これはマイコンにもよると思うのだが……

ここで書いたソフトウェアから見たウォームリセット、リセットハンドラへのジャンプぐらいしかない。

いくつか候補にあったマイコンも見たけど、ほぼこれしかないね。

(1つは他のコアからのレジスタ操作でハードリセットできそうにも見えたが)


一方でこの方法でのリセットができないシステムはないだろう。

割り込みを受けてリセットハンドラへのジャンプというのは誰でもできる。

この方法でどれぐらい完全なリセットになるかという問題はあるが、

OSを立ち上げなおすという動作は概ね実現できるように思える。

個別で停止して、個別にアップデートして、個別に起動する。

起動部分を多少注意して作れば実現できなくはない話である。


もっともOSを分ける構成でも全コアで共通的な機能は分けることができない。

このためコアごとにOSを分けることにどれぐらいメリットがあるかという指摘はけっこうある。

多少なりともブートローダーやOSに手を加える部分が増えるのは事実。

とはいえOSを1つにする場合にはアプリケーション側での工夫が多くなるので、

どちらの方が容易かという話なんだろうなという気もする。


というわけでマルチコアのプロセッサーに複数のマイコンをまとめるのは、

発想としてはありそうだけど、実際には簡単じゃないねという話だった。

他にもいろいろ難題があるんですけどね。Blogに書ける愚痴はこれぐらいで。