目次: RISC-V
結論を先に言うと「面倒くさいけど個人でも買える」です。
Akaria NS31AのEntry Kitのご担当の方と何度かメールをやり取りしていただけで、あっというまに1週間経ちました。この時間があれば、中国や台湾のボードなら注文、支払いは全て終わって、家に届いていますね。さておき個人がNS31A Entry Kitを購入する場合の条件は下記の通りでした。
最近の便利な通販サービスに慣れきってしまったため、かなり面倒くさいのと、そんなことするの?という驚きでいっぱいです。Amazonや楽天がいかに簡単で素晴らしいかわかります。
B2Bのみの販売経路に、個人への販売経路を追加していただいたのは感謝していますが、企業→個人で「着払い」で物が送られるのは初めてで驚きました。
通常は請求料金に送料を乗せます。3万円のボードなら送料を企業側が負担することも珍しくありません。個人でやっているレベルの小規模小売店もできていることです。払う総額は同じでも、個人側の負担を減らそう、料金を明瞭にしよう、という意気込みが欲しかった……。
企業が着払いを使うのは逆(個人→企業)の方向に送るときです。つまり個人側が送料を負担しなくていいように、企業が着払いで受け取ります。修理時の発送では割と見かけますね。
この記事にコメントする
目次: RISC-V
先日(2022年11月12日の日記参照)送ったNS31Aの評価キット購入についての問い合わせの返事が来ました。あまりに返事が来なくて、メールアドレス書き間違ったかな?って不安だったので安心しました。ちなみに返事の内容は、
とのことです。QAフォームを見た時点で、これBtoB販売しか想定してないでしょ!?とは薄々感じていたので、やっぱりか〜と思いました。
というわけで、何かしらの決定&判断をいただけるまでもう少し待ってみます。
メモ: 技術系の話はFacebookから転記しておくことにした。
この記事にコメントする
この記事にコメントする
目次: RISC-V
個人で自社製品を買おうとしたらどうすれば良いか?を調べました。NSITEXEのIPで世の中に出ているものは2種類ありますが、Akaria NS31Aという汎用RISC-V 32bit CPU IPを購入します。
CPU IPそのもの(Verilogのコード)を買うのはライセンス契約等が必要で個人ではほぼ不可能なので、CPU IPを試せるFPGAの購入を検討します。
萩原エレクトロニクスがパートナー企業として評価キットを販売してくれています。しかしNSITEXE NS31Aで検索してもかなり下に評価キットのニュースリリースが出るのみで、製品紹介サイトはありません(NSITEXE製RISC-Vコア評価キット発売について - 萩原電気ホールディングス株式会社)。ニュースリリースですといずれ消えるのでは?大丈夫か……?
ニュースリリースにはAkaria NS31AのEntry Kitの特徴は「発売中」と書いてあるものの、買い方が一切書いていません。この時点で興味のあるエンジニアの3割が脱落すると思います。
めげずに読み進めて下の方にある「NSITEXE製RISC-Vコア評価キット製品紹介」というボタンを押すと、チラシがPDFで出てきます。Interface誌にもこのチラシが載っていました(チラシへのリンク)。
チラシを見ても相変わらず買い方がわからないです。あとQRコードだけという仕様も辛いです。PCユーザーを見捨てないでほしいです。この時点で興味のあるエンジニアの6割が興味を失って脱落すると思います。
めげずにスマホを持ってきてQRコードを読むと、良くわからんQAフォームに飛ばされます(お問い合わせ - 萩原エレクトロニクス)。
出た出た!日本の半導体会社の最大の悪癖「営業にご連絡ください」攻撃です。この時点で興味のあるエンジニアの9割が脱落します。上司に言われて仕事で渋々買う人以外は連絡しませんよ。これ。
QAフォームを見ると会社名が必須で「個人の開発者など用はない、去れ」という気持ちがビシビシ伝わりますが、めげずに「個人ですが何か?」とフォームを埋めてメッセージを送信しました。
しばし待ってみましたが、特に確認メールなどは来ないようです。正常に送れたんでしょうか?不安になりますね。今日はいったんここまでです。買い方がわかったらまた続きを書こうと思います。
中国や台湾のメーカーはボード1つでも売ってくれるし、一瞬で注文できるし海を越えても届けてくれるのに、日本のボードは1日で発注にすら至らないし、すごく面倒くさいです。相当の機会損失していると思います……。
この記事にコメントする
ポッキーの日だそうですが、1(と0)といえば2進数、2進数といえばビット操作ですね(?)。以前 Bit Twiddling Hacks を最新のコンパイラ達に向けて試したときの悲しい結果をメモしておきたいと思います。
試したのはConditionally set or clear bits without branchingという項目で、fがtrueならwとmのビット論理和を、fがfalseならwからmのビットを消去した値を返す処理です。素朴な実装ではif文を使うでしょう。
int cond_set_or_clear1(bool f, int m, int w)
{
if (f)
return w | m;
else
return w & ~m;
}
さきほどのサイトでは最適化版として、条件分岐をなくす、データ依存性をなくす(スーパースカラプロセッサ用)、2つのバージョンを掲げています。まずは条件分岐をなくした版のコードを紹介します。
int cond_set_or_clear2(bool f, int m, int w)
{
return w ^ ((-f ^ w) & m);
}
分岐がなくなっています。なんでこれで同じ動作をするのか?は説明が必要でしょう。fがtrueなら -f = -1となり、-f ^ wはwのビット反転(notと同じ)と同じ結果 -1 ^ w = ~wになります。よって右側の括弧内 (-f ^ w) & m = ~w & mです。
あとは~w & mはw = 0, m = 1のビットだけ1になって残り、あとは全部0になります。w ^ (~w & m) はw | mと同じ結果ですが……そう言われてもわかりにくいので表にします。
| w | ~w | m | ~w & m | w ^ (~w & m) |
|---|---|---|---|---|
| 1 | 0 | 1 | 0 | 1 |
| 1 | 0 | 0 | 0 | 1 |
| 0 | 1 | 1 | 1 | 1 |
| 0 | 1 | 0 | 0 | 0 |
一方fがfalseの場合、0とみなされるので -f = 0となって、-f ^ w = 0 ^ w = wです。右側の括弧内 (-f ^ w) & m = w & mです。w ^ (w & m) は先ほどとは逆でw = 1, m = 1のビットだけ1になって残り、あとは全部0になります。
最後にwとこの結果をxorすることでwとmがともに1のビットだけ0になりますから、w ^ (w & m) はw & ~mと同じ結果です、が……これも表がわかりやすいでしょう。
| w | m | w & m | w ^ (w & m) |
|---|---|---|---|
| 1 | 1 | 1 | 0 |
| 1 | 0 | 0 | 1 |
| 0 | 1 | 0 | 0 |
| 0 | 0 | 0 | 0 |
次にスーパースカラ版のコードを紹介します。
int cond_set_or_clear3(bool f, int m, int w)
{
return (w & ~m) | (-f & m);
}
これは先ほどよりシンプルです。左側の括弧はfによらず常にw & ~mで一定で、右側の括弧の値だけが変化します。
まずfがtrueなら -f = -1となり、-f & m = mです。(w & ~m) | mですが、w & ~mはwからmの1となっているビット位置を0にする演算でした。そこにmをorすると消えたビットは再び1になります。すなわちw | mと同じ結果です。
| w | m | w & ~m | (w & ~m) | m |
|---|---|---|---|
| 1 | 1 | 0 | 1 |
| 1 | 0 | 1 | 1 |
| 0 | 1 | 0 | 1 |
| 0 | 0 | 0 | 0 |
次にfがfalseなら -f = 0となり、-f & m = 0です。よって (w & ~m) | 0 = w & ~mになります。
なぜスーパースカラ向けか書いていませんが、w & ~mと -f & mに依存性がなくて同時に演算できるからだと思われます。じゃあ全部これでいいじゃないか?と思われるかもしれませんが、演算回数を見ると、
2つ目の方式: w ^ ((-f ^ w) & m) neg, xor, and, xorの4回の演算が必要 3つ目の方式: (w & ~m) | (-f & m) not, and, neg, and, orの5回の演算が必要
このため同時に演算できないプロセッサの場合は2つ目の方式の方が良いと言えます。
ここまで長々と紹介しておいてこんなことを言うのは憚られますけど。この手のビット魔術は面白いのでつい手を出したくなりますが、最近のコンパイラに対しC言語レベルでの最適化はあまり意味がないです。
論より証拠でGCC 12.2.0の結果から見てみましょう。
あれだけグダグダ語った3つ目の方式でしたが、なんと2つ目の方式と全く同じバイナリになりました。
GCCだけでは証拠として不安でしょうか?では次にclang 15.0.0の結果も見ましょう。
なんと3つ目の方式は「これ分岐じゃね?」と解釈されて分岐に戻されてしまいました。これが分岐に見えるclangはスゴイですね。私はこのコードを見ても分岐には見えません……。
1つ目の方式と2つ目の方式が違うバイナリになるところを見る限り、全くの無意味ではないです。しかし見やすさでは大幅に劣ります。基本は素朴なコードにしておき、遅くて困る場合のみビット魔術に手を出すべきでしょう。
この記事にコメントする
| < | 2022 | > | ||||
| << | < | 11 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| - | - | 1 | 2 | 3 | 4 | 5 |
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | - | - | - |
25年10月15日
25年10月18日
22年5月5日
25年10月19日
23年4月11日
06年4月22日
25年10月17日
25年10月6日
25年10月13日
20年10月23日
25年10月12日
20年8月29日
19年1月13日
18年10月13日
18年9月3日
18年8月20日
18年7月23日
18年7月22日
18年10月14日
18年11月10日
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報合計:
本日: