一人一党党

一人一人の、一人一人による、一人一人のための政治制度を!

Inferno - MMU無しでメモリ保護

この記事は
Plan 9 Advent Calendar 2019 - Qiita
https://qiita.com/advent-calendar/2019/plan9
の21日目のために書いた。

Plan 9由来なら何でもどうぞとの事なので、このOSから派生した特異なOSについて触れてみた。
Inferno (オペレーティングシステム)
https://ja.wikipedia.org/wiki/Inferno_(%E3%82%AA%E3%83%9A%E3%83%AC%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0)
自分はPlan 9に触れたことが無いので分からないが、
http://shirou.prosou.nu/emacs-wiki/Inferno.html
によると基本的にはほとんど変わらないらしい。
しかしOSの実装方法から言えば、Plan 9Windowsが同じ穴のムジナに見えるくらい、InfernoはPlan 9からかけ離れている。

近代的なOSの重要な役割の一つに、ユーザープログラムが一つくらい異常動作しても、OSや他のユーザープログラムを巻き込まずに対処できることが挙げられる。
特に、ソフトウェア開発者が自らのために作った出自を持つUnix以降のOSでは、開発途中の、言い換えればバグ入りのソフトウェアを動かすことが前提になる。
このためには幾つかの機能が必要になるが、その一つがメモリ保護だ。
OSの基幹コードのあるメモリ領域がデタラメな値で埋め尽くされれば、システムはクラッシュするだろう。
他のプログラムのメモリを読めるならば、うっかりスパイウェアを動かすことができない。
これらを防ぐために、Plan 9Windowsも大抵のUnix系OSも、メモリ管理ユニット(MMU)という回路を積んだCPUを必要とする。

一方Infernoでは、メモリ保護機能の実装にMMU回路を使わない。
というより、メモリ保護機能が無い。
Infernoではユーザープログラムをバイトコードコンパイルして仮想マシンで動かしているのだが、このコンパイル済みバイトコードを上手くイジると、OSが落ちる。
私はLinux上でのInfernoエミュレータでしか実験していないが、バイトコードからframe領域確保命令(0x05 "frame")を見つけて確保領域量を過小にするように書き換えてみたところ、未確保領域アクセスを検出してInfernoエミュレータが終了したり、自力では検出できずにLinux側のセグメンテーション違反に引っかかってエミュレータがクラッシュした。
なのに基本的にPlan 9と同じように使える理由は、そのバイトコードを出力するコンパイラにある。
Infernoに搭載されているプログラミング言語limboは、いわゆる強い型付けの言語だ。
怪しげなメモリアクセスをするソースコードコンパイルの時点で殆ど弾かれ、残りも実行時型チェック用のコードを挿入される。
つまり、Infernoのメモリ保護機能を実現しているのは、OS付属のlimboコンパイラということになる。

MMUを使わないということは、物理マシン上で直接動作するInferno OSと、他のOSのアプリケーションとして動作するInfernoエミュレータで、ほぼ同じ実装方法が使えるということだ。
近年では、MMUをユーザープログラムでも使えるCPUが増えてきたが、使用手続きがCPUやOSによって異なり、使い易いとは言い難い。
MMUを使わないOSなら、通常のユーザープログラムの範囲内の技術で実装できる。
コンパイラによってメモリ保護を行なうInfernoの手法は、OS実装の参考になるかも知れない。

・追伸
Verve (operating system) - Wikipedia
https://en.wikipedia.org/wiki/Verve_(operating_system)
Infernoと異なり、OSの受け付けるバイトコードが強い型付けの命令セットなので、怪しげなバイトコードによるOSのクラッシュを防止できる。

開発ツール開発と、独自命令セット

この記事は
アセンブラ Advent Calendar 2019 - Qiita
https://qiita.com/advent-calendar/2019/asm
の9日目のために書いた。

しかし、カテゴリが「OS」になっていて、他のカレンダーはWindows Subsystem for Linuxとか何とかBSDとかPlan 9とかを題材にしている。
それらに並んでアセンブラとは、どういうことだ?
既存のOSや開発ツールなどを使うな、ということか!

Thompson hackで示されたように、ある種のワームを最初の開発ツールに仕込んでおけば、以後の開発ツールをワームの書かれていないソースコードから構築してもワームが感染し、ワームを取り除くことができない。
勿論、ワームの感染していない開発ツールを使えばいいのだが、何メガバイトもある既存の開発ツールのバイナリを調べて、ワームの有無を判別するのは絶望的だ。
現実的な方法として、異なる二つの開発ツールの出力を比較する方法もあるのだが、二つのツールともに同一のワームに感染している場合に対応できない。
そこで究極の方法が、バイナリの調査が絶望的な既存の開発ツールは一切使わず、何バイトもないショボい開発ツールから出発するものだ。
ショボい開発ツールを使って、もう少しマシな開発ツールを作る。
これを繰り返し、最終的には十分な機能を持った開発ツールを作成することで、ワームに感染していないそれを使い、ソースコードから既存の開発ツールを再構築する。

bcompiler - Bootstrapping a simple compiler from nothing
https://github.com/certik/bcompiler
bcompilerでは、16進数で表記されたバイト列のテキストファイルを、そのバイト列通りのバイナリファイルに変換するだけのコンバータが、出発用の開発ツールだ。
コンバータのサイズは、たったの191バイト。
ワームの有無の判別どころか逆アセンブルまで、人力で何とかできそうな小ささだ。
問題は、bcompilerには移植性が全くないこと。
古き良き32bitのx86linuxにベッタリ。
しかも近年の物理マシンには、Intel Management EngineやPlatform Security Processorなどのバックドアがハードウェアで実装されている。

この移植性と物理バックドアの問題に対応したのがstage0だ。
Stage0 - Bootstrap for the Free Software
https://savannah.nongnu.org/projects/stage0/
https://github.com/oriansj/stage0
開発ツールの構築を、物理マシンではなく仮想マシン上で行なっている。
仮想マシンC言語で記述することによって、移植性を確保しているわけだ。
そして、仮想マシンは必ずしも、ソフトウェアで実装する必要はない。
stage0では仮想マシンの仕様を定めているので、その仕様を満たすようにトランジスタを並べるなりして、自分で物理マシンを用意すれば、stage0のコードがそのまま流用できる。
自作の物理マシンによって、既存の物理マシンに仕込まれているバックドアの問題を回避するわけだ。
ただし、stage0の仮想マシン命令セットは単純なものではない。
殆どの命令は4バイトだが、即値を使う命令は6バイトであり、固定長命令セットではない。
4個の汎用レジスタに同時にアクセスする命令もあり、加算命令と減算命令にそれぞれ6個のバリエーションがある。
物理マシンやFPGAによるソフトコアプロセッサどころか、インタプリタの構築も大変ではないか?

そこで私は、RISC風の仮想マシンを作ってみた。
stage0risc
https://github.com/abo-junghichi/stage0risc
命令の種類は27個しかないし、全ての命令が4バイトの固定長。
その他にも、インタプリタやソフトコアプロセッサを作り易くする工夫を加えたつもりだ。
問題は、肝心の開発ツールは未だ作っていないことだ。

さて、独自命令セットのstage0riscは冗談として、bcompilerとstage0、どちらに見込みがあるだろうか?
bcompilerの方は、現実に存在する物理マシン上で直接動作する。
対してstage0は、独自命令セットを使っているので仮想マシンを介さねばならない。
動作速度の上でbcompilerの方が圧倒的に有利だ。
しかし実際は、stage0の方がbcompilerの先を行っている。
いや、見込みではなく既に、ゴールテープを切っている。
stage0から最新のGNUツールチェーンへ至る道が出来上がっているのだ。
Mes - bootstrapping
https://bootstrapping.miraheze.org/wiki/Mes
開発のし易さの点では、後方互換性が積み重なってグチャグチャになった物理マシンの命令セットより、開発者自身謹製の独自命令セットの方が有利ということなのだろう。

累積レジスタ割付による仮想マシンの高速化

この記事は
言語実装 Advent Calendar 2019 - Qiita
https://qiita.com/advent-calendar/2019/lang_dev
の5日目のために書いた。

言語実装に興味のある人ならコンパイラにも興味があるはずで、コンパイラに興味のある人なら、一度はコンパイラを実装しようとして、コンパイル先命令セットの選択に悩むはず。
スマートフォンの枠を越えてWindowsにまでARMが進出を始めている上に、大学発の命令セットとしてRISC-VがMIPS再来の如く台頭する中、x86ベッタリのコードは恐い。
PA-RISC,Alpha,IA-64(Itanium)…、物理マシンの命令セットは製造元の都合で将来性を絶たれてしまう。
この時、JavaやInfernoのように仮想マシン命令セットに行き着くのは、言語実装に興味のある人ならよくあること。

そんな用途に最も向いていると現在私が考える仮想マシンが、「累積レジスタ割付」を前提とするレジスタマシンだ。
「累積レジスタマシン」とでも呼ぼうか。
レジスタの数に上限のない仮想レジスタマシンの一種なのだが、レジスタの性能に偏りがあり、番号の若いものほど性能が高くなるように仮想レジスタが並んでいる。
これにより、言語処理系を実行時(JIT)コンパイラと事前(AOT)コンパイラに分ける場合に、性能劣化を大きく抑えることができる。

普通の仮想レジスタマシンでは、たとえ仮想レジスタの数に上限がなくとも、どの仮想レジスタも性能が等しいという建前になっている。
このため、変数に割り付ける仮想レジスタの選択に事前コンパイラは悩まずに済む。
使用頻度が高いなどの重要な変数を置くのに、どの仮想レジスタを選んでも性能に違いは生じないからだ。
勿論、物理レジスタの数には上限があるから、全ての仮想レジスタに物理レジスタを割り付けることはできず、物理レジスタを割り付けるものとメモリで済ますものに分ける必要がある。
物理レジスタの数は物理マシンによって異なるから、仮想マシンの仕様しか知らない事前コンパイラでは物理レジスタの割付を行えず、実行時コンパイラですることになる。
が、実行時コンパイラでは、どの仮想レジスタに重要な変数が置かれているか知ることが難しい。
仮想レジスタの選択を事前コンパイラは悩まないので、デタラメに行うからだ。
実行時コンパイラの重さは事前コンパイル済みプログラムの実行時間に加算されるので、実行時コンパイルされたコードの性能向上による実行時間短縮効果を打ち消してしまいかねず、あまり強力な解析を実行時コンパイラはできない。
結果、普通の仮想レジスタマシンでは物理レジスタの活用が難しい。

これに対して累積レジスタマシンでは、仮想レジスタの性能に偏りがあるので、変数の重要性に応じた性能の仮想レジスタを割り付けることで、事前コンパイラ仮想マシン向けコードの性能を高めることができる。
2018年6月17日のブログで触れた論文は、そのようなマシンでのレジスタ割付アルゴリズムを「cumulative register allocation」と呼び4種類ほど紹介している。
"Combining Offline and Online Optimizations: Register Allocation and Method Inlining" by Hiroshi Yamauchi and Jan Vitek
https://pdfs.semanticscholar.org/9a4a/d55afd9159f037aa163cbf4a5a770a49999c.pdf
直訳すれば「累積レジスタ割付」となるだろうか。
実行時コンパイラからすれば、仮想レジスタの番号順に、重要性の高い変数が置かれているように見える。
このため、仮想レジスタへの物理レジスタ割付は簡単で、番号の若い仮想レジスタから順番に物理レジスタを割り付ければ良い。
レジスタ割付が済んでいるので、仮想命令の前後関係を考えずに命令単位でコンパイルするだけで良く、実行時コンパイラが簡単・高速になる。
事前コンパイラは重くなるが、事前コンパイルされたプログラムの実行時間には加算されないので、あまり問題にならない。

問題は、仮想マシンを介してコンパイル・実行されるコードの性能だ。
物理マシンの命令セットへ直接コンパイルする場合は、物理レジスタの数についての知識を事前コンパイラは使うことができるが、仮想マシンへの場合はそうではない。
物理レジスタ数が分かっている状態で行う通常のレジスタ割付アルゴリズムと比べて、累積レジスタ割付の出力するコードの性能はどれくらい落ちているのだろう?
先の論文では、先ほどの4種類の累積レジスタ割付アルゴリズムと、仮想マシン内の物理レジスタ数を知らされた通常のレジスタ割付でベンチマークを採っている。
それらのベンチマークを平均すると、通常のレジスタ割付に対する累積レジスタ割付の性能差は4%以内。
ベンチマークの種目によっては-6%から+10%まで幅がある。
驚くべきことに「-6%」、つまり、物理レジスタ数を分かっている通常アルゴリズムの吐いたコードよりも6%速い結果が観測されたらしい。
ベンチマークのデータ品質が悪いからとも言えるが、4%の差は誤差の範囲だろう。

先に述べたように、仮想累積レジスタマシンでの実行時コンパイラは、実行時コンパイラとしては簡単な方だ。
しかし、移植性が高くてラクチンな、純粋なインタプリタ仮想マシンを実装したいこともあるだろう。
その場合の速度はどうだろう?
結論から言えば、累積レジスタマシンはレジスタマシンの一種だから、最も高速な部類に入る。
"Virtual Machine Showdown: Stack versus Registers" by Yunhe Shi
https://scss.tcd.ie/publications/tech-reports/reports.07/TCD-CS-2007-49.pdf
勿論、レジスタ数に上限がないので、厳密には各仮想命令のoperand fieldは可変長になり、単純なインタプリタ実装では速度は得られない。
しかし、ここでも普通のレジスタマシンとの違いが効いてくる。
累積レジスタ割付により若い番号のレジスタの使用率が上がるので、大きな番号のレジスタを使う頻度は普通のレジスタマシンよりずっと少ない。
ならば、大きなレジスタを扱う仮想命令は動作の確保に留め、効率の追求は若い番号のレジスタしか扱わない仮想命令でのみ行う設計にすればどうだろうか。
例えば、同じ演算を行う仮想命令を二つずつ、若い番号のレジスタしか扱わないoperand fieldが固定長のものと、レジスタ番号に上限はないが効率の悪いものを用意するとか。
累積レジスタ割付により殆どの仮想命令は効率的な方のが使えるので、性能は殆ど落ちないだろう。

このように、コンパイル先に選ぶ仮想マシンとして累積レジスタマシンは最適だと私は考えている。
この記事がコンパイラ作成に挑戦する人の参考になれば幸いだ。

2019年参議院選挙に於ける「一人一党党」視点での各党の評価

参議院選挙も近いので、全国比例区に立候補している各党の政策を、我が「一人一党党」の興味、つまり選挙制度統治機構に絞ってまとめてみた。

政治的ねじれ現象など統治機項の問題に触れたのは、日本維新の会幸福実現党だけ。
まあ、これを解決するには、多数決の仕方を「賛成・反対」から「選択肢A,選択肢B,選択肢C,...」に変えねばならないだけでなく、憲法の定める議会・内閣の関係にも手を入れねばならない。
すると、政権をとるだけではなく憲法改正もしなければならないから、実現のハードルがとても高い。
各党が公約にできないのは無理からぬ所か。

選挙制度については、やはり、現行制度への特化が激しい主要政党にとっては、触れたくないもののようだ。
対して小政党・確認団体はどうかというと、さすがに小選挙区制を目指す団体はないようだが、幸福実現党オリーブの木構成員が中選挙区制を唱えていて、見てられない。
中選挙区制」が指すものを、この人達は分かっているのか甚だ疑問。
仮に1994年までの日本の選挙制度とするなら、一つの選挙区で当選できる人数は最大でも6人までで、7位以下の票は死ぬ。
8位以下になろうものなら泡沫候補のループに嵌るが、この人達は7位以上に滑り込む自信、いや、過信があるのだろう。
あるいは単に、選挙制度の恐ろしさを自覚していないのか?
1994年の選挙制度改正の破壊力を身を以って学んだはずの、社民党の公約は呆けてしまった。
そんな中、選挙制度に対する感性が一番鋭いのは労働者党のようだ。
共産党の主張する半端なブロック制すら許さない。

総じて、「一人一党党」の政策に最も近いのは、労働者党のようだ。
彼ら・彼女らに勝利あれ。

以下、ネタ元。
我が党に興味の無い人でも、各党の公約入手先として参考になるかも。

幸福実現党
2019年5月主要政策
http://publications.hr-party.jp/files/policy/2019/001/origin/all.pdf
「116
政治への新規参入の障壁となっている公職選挙法や政党助成法などを見直して、競争条件の公平化を図ります。

衆議院選挙制度については、死票が多いなど弊害のある小選挙区制を廃止し、中選挙区制に改めます。

118
参議院の廃止により、国政における意思決定の迅速化を図ります。
二院制を維持する場合は、参議院に「 廃法府」としての機能も持たせ、衆議院との機能分化を行うとともに、不要な法律や規制の廃止を進めます。

中選挙区制」を目指す、自信過剰な党。
統治機構について触れているところは立派だが、衆参両院のうち参議院の方を廃止するという、二者択一のうち間違った方を選んでいる。
解散総選挙中は、残った唯一の立法府である衆議院は空っぽになる。
この時を狙って有事を仕掛けられたら、超法規的措置に頼るしかない。
半数改選の参議院では、総選挙中も議員が半分残っているから、一院制の元で総選挙中でも、このような隙は生じない。

日本共産党
https://www.jcp.or.jp/web_policy/2019/06/2019-bunya44.html

衆議院選挙制度について、小選挙区比例代表並立制を廃止し、民意を正確に反映する比例代表制への抜本改革を行います。議員総定数は元に戻し、全国11ブロックを基礎とした比例代表制にすることを提案します。
参議院議員選挙制度について、総定数の削減は行わず、多様な民意が正確に反映される比例代表を中心とした選挙制度にすることを提案します。

政党助成金をもらう資格がありながら、助成制度の存続だけでなくもらうのも拒否し続ける筋金入りのこの政党がなぜ、衆議院には死票が増えるブロック分割を主張するのか理解できない。

社民党
http://www5.sdp.or.jp/election_sangiin_2019

得票率と議席率の乖離をなくし、多様な民意が反映するよう、比例代表を中心とした選挙制度に抜本改革します。

「…を中心とした」とか言葉を濁すとは、選挙制度について、理想像を持っておらず党利党略の妥協案としか理解できないからか?

・労働の解放をめざす労働者党
http://wpll-j.org/sinntoukouryoukiyaku.html

七、社会主義の勝利と共に、あるいは社会主義をめざす闘いの過程で勝ち取るべき、労働の解放をめざす労働者党の具体的な要求

3、不正で、不公正な現行選挙制度と議会運営の根本的で、徹底的な民主主義的改革の実行。

労働者、勤労者の意思が正確に表現される選挙制度の実現。一切の選挙参加及び選挙運動の規制の原則的撤廃と、労働者の自由な政治闘争の保障。小選挙区制の廃止と全国単一比例代表制の実施。衆参共に、自由で無制約の政党及び個人の選挙参加制の実現。腐敗大政党にのみ有利で、民主主義の精神に根底からもとる、不当不正の供託金制度、政党助成金制度の即時廃止。

「七 具体的な要求」には18の項目があるが、そのうち3番目にこれを持ってくるほど、この党は選挙制度・議会制度を重要視している。

オリーブの木
https://oliveparty.jp
この党は、さらに小さな複数の党の連合体であり共通政策を掲げているが、そこには選挙制度が全く触れられていない。
恐らく、戦犯は「護憲保守政党・平和の党」だ。
基本政策 | 平和の党
https://heiwanotou.com/basic

国会議員の定数と歳費削減
中選挙区制の復活
議員の文書通信交通滞在費の削減と公開
議員年金復活反対、企業団体献金の禁止

望み通り中選挙区制が復活した暁には、オリーブの木は改選議席を失うと思う。

・れいわ新選組
選挙制度・議会制度に関する政策が見つかりません。
知っている方が居られたら、コメント下さい。

NHKから国民を守る党
安楽死制度を考える会
党名から言って、選挙制度についての政策は期待できない。

公明党
https://www.komei.or.jp/campaign/sanin2019/_assets/pdf/manifesto2019.pdf
選挙制度についての言及が見つからない。

自民党
https://jimin.jp-east-2.storage.api.nifcloud.com/pdf/manifest/20190721_manifest.pdf

選挙人の投票機会を確保するため、郵便等投票制度の対象者の拡大を図ります。
また、幅広く意見を聴きながら被選挙権年齢を引下げの方向で検討するとともに、選挙運動規制等の公選法全般の見直しも進めます。

現行制度(小選挙区比例代表並立制)を変えるつもりはないようだ。

・国民民主党
https://www.dpfp.or.jp/assets/election2019/downloads/pamphlet_20190613.pdf

3. 議員定数削減と参議院選挙制度見直し
国民民主党が提出した参議院議員の定数を6減らす法案の成立を目指します。
衆参両議院のあり方を踏まえ、合区解消など参議院選挙制度の抜本的見直しを行うとともに、国会議員の定数削減など身を切る改革を進めます。

「全国一区」や「道州ブロック」ではないことから、「合区解消」が意味するのは一票の格差の問題が大きくなる「鳥取・島根や徳島・高知の分離」ということか!?
北海道民に嫌われるのは確実。

立憲民主党
https://special2019.cdp-japan.jp/rikken_vision_04/

民意が多様化・複雑化した現在の社会に対応するためには、一人ひとりの現実に真正面から向き合う政治が必要です。
参加民主主義を促進することで、多様な声を受けとめるための仕組みをつくります。
熟議に不可欠な情報やデータを厳重に管理し、情報公開の徹底と国会による行政の監視を強化します。
○20歳から立候補できるよう被選挙権年齢引き下げを行い、立候補休暇制度を創設します。

単記非移譲式投票や小選挙区制のまま被選挙権を広げたら選挙結果がどうなるか、被選挙権を広げる効果があるのか、この党は分かっていないのか?
それとも、小選挙区制の方が自分たちには有利だと信じる民主党時代の傲りか?

日本維新の会
https://o-ishin.jp/sangiin2019/common/img/manifest2019_detail.pdf

1. 身を切る改革・徹底行革、国会改革~小さく合理的、効率的な行政機構に~
(14)選挙制度改革(被選挙権年齢を 18 歳に引下げ)

7. 統治機構改革
(1)地方分権(道州制)・(究極的には)一院制・首相公選制
(2)大阪都構想の実現。グレーター東京構想を
(3)東京・大阪のツインエンジンを先頭に自立分散型国家へ
(4)消費税の地方税化。交付税制度等の見直しにより地方共有税の創設
(5)内閣の機能強化(予算編成権・組織編成権の内閣への一元化)
(6)参議院の抜本改革(自治体首長と参議院議員の兼職禁止規定を廃止)

被選挙権拡大については、立憲民主党と同じまちがい。
一院制・首相公選制」は「衆参のねじれ」とは別のねじれ現象「首相と院を別々の政党が獲る」が生じる。
アメリカなど大統領制の国々では時々起こるし、日本の地方自治体も首長と議会を別々に選挙するから、このタイプのねじれ現象が見られる。
当会の母体である大阪維新の会地方自治体に長く関わっているはずなのに、「首長と議会のねじれ」を気にしないのか?

メルセンヌ素数でxorshift疑似乱数の軽量化

とってもお手軽な割にそこそこ高速で高品質な疑似乱数生成アルゴリズム「xorshift」。
32bit版などの実装では、乱数生成一回あたりxor演算とshift演算を3組、計6回演算命令を使わねばならない。
ところが64bit版実装では、xorとshiftの組を2組しか使わずとも、2の64乗の周期が出る。
そこで、31bit版などbit数がメルセンヌ素数の場合、2組で可能か試してみた。
一般的なCPUのレジスタは32bitや64bitなど2のベキ乗なので、bit数を調整するためにand演算でbitmaskをかける必要がある。
しかしand演算はxorやshfit同様に軽い整数演算だ。
従って、xorとshiftの組を一組、すなわち整数演算を二つ減らせるなら、and演算一つ払っても整数演算ひとつ分だけ高速化できる。
メルセンス素数なら、周期は1かbit幅一杯かのどちらかなので生成パラメータが見つかる可能性が高そうだ。
しかも周期が素数なので、乱数を利用する側のプログラムの持つ周期と同期してしまう可能性が低い。
普通のxorshift疑似乱数は周期が素数ではないので、利用するプログラム側と組み合わせた周期が小さくなる場合がある。
パラメータ探索には下記のサイトのpythonスクリプトを拝借した。
Google Chromeが採用した、擬似乱数生成アルゴリズム「xorshift」の数理 – びりあるの研究ノート
https://blog.visvirial.com/articles/575
31bit版と5bit版しか試していないが、例えば31bit版だと14組も生成パラメータが見つかった。
bitmaskを即値として演算命令に格納しないと、命令節約効果が打ち消される。
下位bit側をクリアするbitmaskなら、符号拡張により即値フィールドを小さくできる。
即値フィールド制限の厳しいRISC命令では不可欠だし、制限の緩いx86でも命令長節約になる。

--- C言語コード ---
#include <stdint.h>
uint32_t xorshift31(void)
{
    static uint32_t seed = 2;
    seed = seed ^ (seed << 7);
    seed = seed ^ (seed >> 12);
    return seed = seed & (~1);
}

--- x86へのコンパイル結果 ---
00000000 <xorshift31>:
   0:   8b 15 00 00 00 00       mov    0x0,%edx
   6:   89 d0                   mov    %edx,%eax
   8:   c1 e0 07                shl    $0x7,%eax
   b:   31 c2                   xor    %eax,%edx
   d:   89 d0                   mov    %edx,%eax
   f:   c1 e8 0c                shr    $0xc,%eax
  12:   31 d0                   xor    %edx,%eax
  14:   83 e0 fe                and    $0xfffffffe,%eax
  17:   a3 00 00 00 00          mov    %eax,0x0
  1c:   c3                      ret

コンパイル結果での0x14バイト目の命令の長さは3byteしかないが、符号拡張により4byteのbitmaskをかけることができている。
x86は2オペランド命令であり、演算結果を格納するために元データを破壊するため、xorとshiftの組ごとにデータ複製のためのmov命令が余計に加わっている。
xorとshiftの組を3組用いる32bit版実装では、31bit版より2命令多く必要になるはずだ。
上記31bit版の命令数が10個なので、2命令分の増加は2割増し。
なお、左シフトのパラメータを3以下にすると、x86の場合元データを破壊しないlea命令が使え、mov命令を回避できる。
31bit版の有効なパラメータとして(3,28)があり、これを使うと命令数を9個に減らせる。

統計不正が国の根幹を揺るがす犯罪になる国は似非民主主義国家です

最近は厚生労働省の統計不正が話題の様で、私は不思議に感じる。

神戸新聞NEXT|社説|ずさんな統計/民主主義の根幹に関わる
https://www.kobe-np.co.jp/column/shasetsu/201901/0011969710.shtml
確かに、統計不正は政権の判断には大きく影響するかもしれない。
しかし、特に今回の勤労調査や経済調査に限れば、「国民の判断」には殆ど影響しないはずだ。
言い換えれば、それら政権の存続・交代を左右する選挙に於いては、今回の不正の影響は少ないはずだ。

確かに、国民全員の経済や勤労状況は統計でしか知りえない。
ある政策Aで大半の国民の所得が向上するなら、政権はその政策Aを支持すべきだろう。
しかし国民個々の経済や勤労状況は、国民個々が一番熟知しているはずだ。
そして選挙で個々の一票に託されるのは、その票を投ずる個々の国民の意見であり、国民全員の意見ではない。
その政策Aの恩恵から漏れる国民の一人Bさんについては、たとえその政策Aが政権の支持すべき政策だとBさん自身が理解していたとしても、政策Aへ支持の一票を投ずるのは誤りだ。
Bさんの一票はBさん個人の意見を代表すべきで、国民全員の意見を代表するのは誤りであり、その投票行動に於いてBさんは国民全員の意見なんて無視すべきだ。
国民全員の意見は、開票結果の集計、選挙結果で得られれば十分だからだ。
個々の一票に託されるのが国民個々の都合であっても、その集計では、国民個々で相反する利害は打ち消し合い、国民全員に共通する意見のみが浮かび上がる。
もし、Bさんの意見ではなく全員の意見をBさんの一票に託したら、Bさんと相反する国民の意見が、打ち消されないまま反映され、「国民全員の意見」が歪められてしまう。
こうして誰も個々の我侭を投票し無かった結果が、誰の我侭も実現しない「アビリーンのパラドックス」だ。
アビリーンのパラドックス - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%93%E3%83%AA%E3%83%BC%E3%83%B3%E3%81%AE%E3%83%91%E3%83%A9%E3%83%89%E3%83%83%E3%82%AF%E3%82%B9
このことは特定個人のBさんにとどまらない。
全ての国民は選挙時に、自分の意見を最優先すべきであり、国民全員の意見や統計など気にすべきではない。
選挙に於いて国民全員の統計なんて誰も気にしないのであれば、その統計が不正であろうと公正であろうと同じように、選挙は行われるはずだ。

あるいは選挙それ自身が、国民全員を対象とする統計の一種といえる。
選挙とは、個々の国民の政治的意見を集計したものだからだ。
個々の国民の○○状況を集計したものが○○統計ならば、選挙は政治的意見の統計だ。
だから、不正統計が別に行われていても、その統計に依存することなく独立して選挙は動く。
元々、比例代表制選挙制度で構成された議会は「国民の縮図」と言われる。
構成員の100%が議員職に就いているという凄まじく偏った構成であるにも拘らずだ。
正確には「国民の『政治的意見』の縮図」なのだが、そうであるためには、あたかも議員職なんて一度も経験した事のない彼らの支持者達を複製したかの様に、個々の議員は振る舞わねばならない。
だから「国民の複製の縮図」ともいえる。
もちろん、依然として複製は版元とは異なり、複製に富を配分しても版元は全く豊かにはならない。
しかし版元と同じ情報は持つから、複製に対して統計をとれば、版元の統計結果が得られる。
ならば、その元となる開票結果には、縮図にする前の国民の状態が複製されているはずだ。
そして比例代表制に限らず小選挙区制などに於いても選挙である以上、開票結果=国民の複製は集計されている。
つまり、比例代表制に限らず、選挙は統計のバックアップ機能を持つ。
マトモな民主主義国家ならばマトモな選挙が行われるはずで、統計不正単独では大した問題にはならないはずだ。

逆に言えば、統計不正が重大な問題になるということは、統計不正とは別に選挙の機能不全も存在することになる。
そして民主主義国家では、統計不正より選挙の機能不全の方が重要だ。
独裁国家でも統計調査をやっていることから分かるように、統計のバックアップは選挙でできても、選挙のバックアップは統計ではできない。
したがって、この国が民主主義国家を目指すのであれば、統計不正は話題にならない。
統計不正が大した問題でない場合は言うまでもない。
そうでない場合は、より重要な選挙の機能不全の話題に埋没するはずだからだ。

しかし先に述べたように、どうやら統計不正は話題になっているようだ。
このことは、選挙の機能不全が存在しながら、それが話題になっていないことを意味する。
これこそ、民主主義の根幹に関わる。

--- 題名のネタ元 ---
統計不正は民主主義の根幹を揺るがす犯罪です
https://anond.hatelabo.jp/20190206194752

Windows10のライセンス認証をせずに20年間放置した結果

20年くらい後の予言ではない。
2年くらい前の記憶。

私はLinux使いであり、主に使っているパソコンもLinuxを入れているが、テストプログラム用などのためにWindowsを入れた仮想マシンも用意している。
現在はWindows10だ。
当然、Windowsの本格使用は考えていないので、ライセンスを購入する気が起きない。
だが、WindowsXPのように90日(だったかな?)過ぎると実質操作不能になり、いちいち再インストールするのも大変だ。
しかしネットで検索してみると、Windows10については猶予期間について明確な情報が得られなかった。
そこで、Windows10を仮想マシンにインストールしている点を活用して、仮想マシンを「タイムスリップ」させることにした。
とはいえ、アインシュタイン相対性理論に挑戦するわけではない。
仮想マシンのエミュレートしている内蔵時計を20年分進めるだけだ。
しかし、仮想マシン内部の20年後の状態をシミュレートするには十分だ。
私の使っている仮想マシンソフトであるQEMUでは
qemu-system-x86_64 -rtc base=2040-2-30 ...
のようにコマンドラインオプション "-rtc base=..." を使う。
その結果、WindowsXPとは違ってWindows10では、OS操作が不能になるようなことはなかった。
ライセンス認証をしないとwindows updateを受けられないのだそうだが、インターネットなどに繋がないオフライン状態など、セキュリティ上の脆弱性が問題にならない使い方なら、ライセンス認証をしなくても支障はなさそうだ。