【Cortex-】 やっぱARMっしょ part10 【AxRxMx】©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
ARMデバイス、ARMボードについて組込系ARM全般のスレ
時代は「やっぱARMっしょ」
省電力ニーズの高まりを背景に海外チップベンダーはもとより国内勢も参戦
ホビーとしてのマイコンからスマートデバイス用プロセッサまで
ARMコアを持つチップやボードのラインナップは今まさに百花繚乱
【前スレ】
【Cortex-】 やっぱARMっしょ 9 【AxRxMx】
http://wc2014.2ch.net/test/read.cgi/denki/1399381482/ >>759
「普通」とは人それぞれ
Pentiumなどは除算ハードを持つ
これがバグったのが有名なX86のFDIVバグ > Pentiumなどは除算ハードを持つ
> これがバグったのが有名なX86のFDIVバグ
浮動小数点演算の除算のみサポートしないアーキテクチャなんて存在するか? 乗算命令は並列化が可能だから時間かからないけど
除算命令は時間かかるね
x86でも64bitの除算命令が30クロックくらいかかってる リレー計算機で割り算するとガチャガチャした番組思い出した > ARMはともかく32bitの出来がひどい。何がひどいか? RISCなのに汎用
> レジスタが16本しかない、その内の3本はプログラム関連で使っちゃう
> ので、汎用に使えるのはたった13本。これで、ロード/ストアアーキ
> テクチャのハンドリングをしなきゃならない。そうするとコンパイラが
> 効率的なコードを吐けない。ので、コードステップが非常に長くなる。
コンパイラの出力見たことないんだろうなあ、というのが率直な感想。 >>760
あるかと言われたら、
組み込みでどうかは分からないけど乗算器とニュートン法で
除算してた過去のcpuはあった。
ただieee754が使われるようになってからは精度保証が
難しいからないんじゃないかと思う >>764
R13=スタックポインタ
R14=リンクレジスタ
R15=プログラムカウンタ
32bitのARMのレジスタは実質13本なのは事実
演算はすべてレジスタ-レジスタ間のみ
x86のようなレジスタ-メモリ間の演算を行う命令は存在しない
64bitのARMでも
X30=リンクレジスタ
X16、X17=プラスマイナス128MB以上の範囲への
ジャンプやサブルーチンコールする時にリンカが使うためのリザーブ
といろいろと使えないレジスタがあるのは事実 >>764
パイプライン崩さない様にとかで、ステップ数増える事も有るしな。
レジスタ多いと、命令の中の、レジスタ指定部分のビット数増えてしまうから、多ければ良いとも言えない。
レジスタ用途限定した方が、ロジックがシンプルになるので、クロックの高速化しやすい。 >>767
>レジスタ用途限定した方が、ロジックがシンプルになるので、クロックの高速化しやすい。
性能重視設計のCPUはレジスタリネーミングという手法を使ってるから
内部的には100を超える物理レジスタ持ってるけどな
レジスタフィールドの長さの制限とレジスタ数の兼ね合いで
一番バランスがいいのが32個なのでは?
性能重視設計のRISCプロセッサの多くが32個だからね レジスタ16個は糞と主張するやつは今しか見えていない
半導体の集積度が向上したおかげで
今現在はレジスタ32個がよさそう、というだけだ
未来では恥ずかしげもなく32個は糞、バランスで1G個がいいと言うだろうさ 命令の基本が分かってない
レジスタ番号で命令長が食われる。1G個で3オペランドだと、レジスタ指定で90ビット。
1G個のレジスタアクセスは遅すぎて使えない 40年前は8ビットCPUが主流。今は8倍の64ビット
同じペースなら40年後には512ビットCPU。90ビットなんて屁みたいなもんよ >>771
50年持ったけど息切れしてるムーアの法則って知ってる? ソシオネクスト、ARM Cortex-A53を24コア内蔵するサーバー向けSoC - PC Watch
http://pc.watch.impress.co.jp/docs/news/1029735.html >>774
いや、俺も>>772氏と同意見だよ。
「同じペースなら」と言ってるが、512ビットCPUが必要な根拠が曖昧。
このスレな気がするが、誰かが調査したらレジスタが一番多く使われる13ビットまでとか。
32bit→64bitも、アドレス空間拡大が主目的だし。
同じペースで拡大するのも不明だしね。
(40年前でなく30年前だと思うし、それから10年で32bitになった。が、64bitになるには15〜20年必要だった)
(つまりビット数拡大は、鈍化傾向と言えるだろう) そう言うのをネタにマジレスっていうんだぜ
空気読めない奴多いんだな ネタにマヂレスじゃなくてアホをかまうなが正しいんじゃね CMSIS5リリース
ARM-software/CMSIS_5: CMSIS Version 5 Development Repository
https://github.com/ARM-software/CMSIS_5 >>776
旗色が悪くなるとネタで逃げる。。。
だったら最初っから出て来なければいいものをw >>780
旗色ってなんだ?この流れでは俺は初めて書き込んだけど
くやしいのうって言って欲しいだけか? 40年も512ビットもペースもどうでもいいんだよ
>>769の言う「今しか見えていない」、つまりCPUは進化し続けてるってこと言ってるだけなんだから 512bit プロセッサって、VLIWアーキテクチャだよね! 大阪府三島郡島本町は
イジメ被害者の人権をどう考えてるの
暴力肯定いじめ容認? 信じられないかもしれないけどCPUアーキはこの
50年間近くそんなに進歩してない。
今のCPUは基本的に1960年代後半に作られたIBMの
メインフレームCPUの技術が主体。
スーパースカラ、レジスタリネーミング等のアーキは50年前の技術。
進歩したのはデバイステクノロジで、1チップ化され劇的に
安くなった事とクロック周波数とコア数。それとメモリサイズの増大。
それを支えたのがムーアの法則。だけどもう終わり。
今までと同様に機能/性能がどんどん増えるという幻想は捨てなさい。 ほんと空気読めないのなw
ところで>>773見て思い出したけどOpteronAって物は出荷されてるのかね
鯖系向け製品はずっと出す出す詐欺だよなぁ 今のcore i7はAVXというVLIWアーキテクチャやないか(スレチ) 分かったよ。
> ほんと空気読めないのなw
→悔しそうだなwww。
出てこなくていいよ 512bitプロセッサって
数十回程度のループカウンタに使うレジスタも512bitになっちゃうわけ?
もったいないお化けが出てきそう > 512bitプロセッサって
> 数十回程度のループカウンタに使うレジスタも512bitになっちゃうわけ?
64bitプロセッサのintのサイズは64bit、とか思ってそうだな >>794
一般にはILP64とかLP64とかLLP64とか言われてintを32/64bitどう扱うか
複数モデルがある。
なんてこと知らんだろうけど。
#また湧いて来た気がする > 一般にはILP64とかLP64とかLLP64とか言われてintを32/64bitどう扱うか
> 複数モデルがある。
>
> なんてこと知らんだろうけど。
>>793の周囲ではこういうのが知識自慢として通用するのかw >>64bitプロセッサのintのサイズは64bit、とか思ってそうだな
これが浅はかな間違いだってことよ。
知らないなら知らないって言えば良いだけなのに。
揚げ足取ろうとして自爆したでしょ。 > >>64bitプロセッサのintのサイズは64bit、とか思ってそうだな
>
> これが浅はかな間違いだってことよ。
> 知らないなら知らないって言えば良いだけなのに。
> 揚げ足取ろうとして自爆したでしょ。
日本語の読解力ないのが自慢かな? >>796
℃玄人臭する人好きじゃないから退散するわ。 > 退散するわ。
面白いオモチャと思ったのに残念w >>798
おまえ、消えてくれていいんだよ。誰も困らないから。 ATMELのSAM7使っててgccでchan氏のFatFsをExFat対応オプションでコンパイルすると
64bit-intでライブラリ関連のリンクが出来ないって怒られて
リンカスクリプト修正して通ったら
なんか出来たバイナリが1Mbytes近くに膨れ上がり
追加したセクションをNOLOADに再修正した思ひで >>793の
> 一般にはILP64とかLP64とかLLP64とか言われてintを32/64bitどう扱うか
> 複数モデルがある。
>
> なんてこと知らんだろうけど。
や>>795の
> これが浅はかな間違いだってことよ。
> 知らないなら知らないって言えば良いだけなのに。
> 揚げ足取ろうとして自爆したでしょ。
の意味がマジわからん。
>>792の「(>>791は)64bitプロセッサのintのサイズは64bit、とか思ってそうだな」をどう解釈したらこういうレスがつけられるんだろう? intは必ずしも64bitとは限らないと言ってるのを「intが64bitは絶対ない」みたいに曲解したのかな? >>802
端から見て、あんたがおかしい。
> 絶対ない」みたいに
誰が絶対と言った?
勝手に脳内妄想し、それに絡んでどうする? >>803
> > 絶対ない」みたいに
>
> 誰が絶対と言った?
誰も言っていないことをそう曲解したのかな?という推測だけどこれに絡んでくる意味も分からんな。
違うと言いたいなら
> 一般にはILP64とかLP64とかLLP64とか言われてintを32/64bitどう扱うか
> 複数モデルがある。
>
> なんてこと知らんだろうけど。
や
> これが浅はかな間違いだってことよ。
> 知らないなら知らないって言えば良いだけなのに。
> 揚げ足取ろうとして自爆したでしょ。
はどういった理解に拠るものか合理的に説明してくれ。 Arduino互換でIoTできる??Wi-FiとRTCを搭載したArduino互換ボード「BiZduino」 | fabcross
https://fabcross.jp/news/2016/20161116_wifi_rtc_bizduino.html ARMでx86エミュとかめっちゃ遅そう
AtomかCeleronの方が早くて安いやろ(笑) >>808
記事にはx86エミュレーター上でWindows10を動かすと書いてあるけど、OSごとしなくてもいいだろうに。 >>809
>ARMでx86エミュとかめっちゃ遅そう
>AtomかCeleronの方が早くて安いやろ(笑)
intel は cortex-a 対抗の atom の開発を諦めたんじゃなかったっけ?
記憶が曖昧だけど
だとしたら、win-rt がこけた ms にはもうこれくらいしか打つ手はないんじゃね? OS 動かせるぐらいの完成度って言いたいんでしょ
ネイティブで動かしたいんなら手直ししてリコンパイルすればいいだけだし >>811
https://ja.wikipedia.org/wiki/QEMU
> QEMUの特徴として、中間コードを介して動的コンパイルを行うことに
> より、x86、PowerPC、SPARC、ARMなど多くのホストCPUに対して多くの
> ターゲットCPUを高速にエミュレーション可能である事が挙げられる。 >>815
ありがと
ということは、
cpuエミュレーションは新しくなくて
biosエミュをしっかりやってるから
OSが立ち上がると考えると妥当なのかな? でた、煽ることしかできない口だけ先生
先生。何か役立つこと言ってみてくださいよ
主に人間性の面で期待してませんが、一応頼んでみます >>816
QEMUのエミュレーションはとっても遅いよ
ARM上で今のx86のWindowsを動かすには実用な速度で動作しない
もっと別の高速エミュレーションの技術使うはず >>819
OSはエミュレーションせずにWinRTを使うな、俺がアーキテクトならw
別の高速技術と言ってもQEMUの中間言語を止めて、ダイレクトコンバージョンするしか無いっしょ。
後はコンバージョンするコアと、実行するコアを分けるとか。
ただWinNTの DEC Alphaプロセッサポートは、一度x86コードを実行するとコードをHDDに保存し、2回目はコンバージョン不要にしていた筈。
あの技術を復活させれば大化けするかもね。 >>11
ラズベリーパイは、本来教育用だからな。
年単位で連続運転とか、考えられてない。 >>820
XboxOneの下位互換機能がそれを使ってたとオモタ >>825
ほぉ〜、使われてたんだ。
エミュレーター、ARMなAndroidやiOS上でWin10が動いたら面白いけど、いいとこWinPhone用なんだろうな。 >>826
ARM WIN10+WoWの可能性が高い MacがPowerPCになった頃に盛り上ってたなぁ
今はバーチャルコンソールくらいか… >>822
>FX!32だっけ。。
FX!32とWineは同系列Wineはエミュレータではないと説明している。
そしてFX!32と同等の技術ではWindows10というOS自体は動かせない。
つまり
単なるx86アプリ限定のJITコンパイラか(エミュレータ誇張)か
超低速のqemuの類(OSも動く)の2つしか考えられない。
処理速度から考えれキャッシュ超大食いのx86をキャッシュが少ないARM
ホストとかはありえない。
単なるJITコンパイラでは従来のWin32な大型アプリでWineで動くのが少ない
ようにゲームやら重量級のビジネスソフトあまず動かない。
つまりx86エミュレータなどでも動くように作り直しが必要になる。 >>822
英語ソースで検索してみると、ARM用のエミュレータではx86ネイティブアプリを
サポートしないと書いてある、ただしWindows10アプリをサポート、
その意味はOSが動くわけじゃない、
Windowsストアで販売される特殊なユニバーサルアプリ限定だってことよ なんだ、過去の資産が使えるわけじゃないのか
あまり成功しそうな感じがしない取り組みだね 今あるARMじゃ力不足で過去の資産が使えないって言い切ってるだけだろw
未来のARMはデスクトップPC用として使われるようになるかもとも言われてるってのに・・・ >>833
.NET アプリは中間コードだから、難しくないと思う。 >>836
.netはwin系はmsがとっくにサポートしてるしそれ以外はmonoあるだろ・・・ ねぇねぇ、LPC810ってもうディスコンで流通在庫のみなの? >>839
ttp://www.nxp.com/jp/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m0-plus-m0/lpc800-low-cost-cortex-m0-plus/low-cost-32-bit-microcontroller-mcu-based-on-arm-cortex-m0-plus-core:LPC810M021FN8
ここの「購入/パラメータ」タブの「ステータス」を見ると「Active」となっています。
製造中止品は、NXPでは「No Longer Manufactured」と表示されるようです。 SymbianなPsion 5でDOSエミュレータ動かしてたなぁ >>840
確かにActiveだ・・・
でもあの Digkey で出てこないし、マルツが75円、千石が150円なのに
マウサー・秋月が300円なんだよなぁ、微妙に怪しい・・・。
なんでそんなことを心配しているかというと、今更こんな
基板を作ったからだ。
ttp://aid.her.jp/ucomJOCKEY/81X/ >>842
デジキーはどうやら、売れない商品は取扱いを止める様だ。 >>843
そうなんだ、扱わないものはないポリシーかと思ってた。
>>844
秋月のLPC810が売れまくったということか。俺ものべ10個ぐらい買ったしなぁ。 いまどきDIPのマイコンが工業製品の部品として需要があるとも思えないので
メーカーがアマチュア向けに宣伝と教育目的で用意した製品で今までは採算は
ある程度目をつぶった値段付けがされてたのかなという気はする。
PICやAVRにDIPの製品が多数あるのはわけわからん。 普段からDIPマイコンを作っているマイクロチップでは
DIPでもQFPでも製造コストは大差ないと思う。
NXPは普段はDIPマイコンは作っていないので、
LPC1114FN28とLPC810については特別対応で
余分なコストがかかったんじゃないだろうか? >>847
DIPもQFPも同じリードフレームへのプラスチックモールド、同じ生産ラインで作れる。 DIP作ってないメーカーでも、DIPをQFPと同じコストで作れるって言ってるんでしょ
マイクロチップでもどこでもコスト同じ程度になるわきゃないのに >>850
その通り
>>849
QFPは、リードフレームから切断する時にフォーミング(足の折り曲げ)をする。
それはDIPも同じで、切断と曲げを同じ工程でやる。
なのでコストは基本的に同じ。
細かい事を言えばプラスチックの使用量が違うとか、リードフレームの購入単価が違うとか、バリ取りの面倒さが違うとか、段取り費が違うとか、作っている工場の人件費が違うとか色々あるだろう。
が、流石にそんな細かな差異は知らんw そんな細かいものによるコスト差はそりゃないに等しわ
極論言えば、QFPしかない100円のIC作ってる会社が「DIPを2つだけ欲しいんだ、経費込み込み200円」って作れるかってことだよww リード加工があるから同じって・・・それなら2SC1815もディスコンにならなかったんじゃね >>853
儲からず、供給責任が無いなら生産中止にする。それだけのことさ。 今はもうピンヘッダも面実装になりつつある時代だからな
ホビーユーザーもリフロー炉やヒートガン必須になっていくだろう >>852
チップ100円で経費込みで200円とかないわ。
そういうコスト削減するのは100円のチップで悲鳴上げているから
1円の差で不採用 【速報】Microsoft、2017年に“ARMベース”のフル機能Windows 10を投入 〜Win32アプリも動作 - PC Watch
http://pc.watch.impress.co.jp/docs/news/1034038.html ■ このスレッドは過去ログ倉庫に格納されています