【Cortex-】 やっぱARMっしょ part10 【AxRxMx】©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
ARMデバイス、ARMボードについて組込系ARM全般のスレ
時代は「やっぱARMっしょ」
省電力ニーズの高まりを背景に海外チップベンダーはもとより国内勢も参戦
ホビーとしてのマイコンからスマートデバイス用プロセッサまで
ARMコアを持つチップやボードのラインナップは今まさに百花繚乱
【前スレ】
【Cortex-】 やっぱARMっしょ 9 【AxRxMx】
http://wc2014.2ch.net/test/read.cgi/denki/1399381482/ >>505
こいつ本当の馬鹿だな
2^nなら、n>1なら必ず4の倍数だし、n.>2なら必ず8の倍数になるわ。こいつ学校で指数計算を理解できなかったのか。
たがらと言って32bitCPUだからってアドレスバスは32本とは限らないし、64bitCPUだからってアドレスバスが64本出てるとは限らない。データバスもな。 >>506
１２はある。ＴＬＣＳ１２を使ったことがある。
２８は知らない
但し、12は元々キャラクタマシン（ASCIIを1度に読み書きできる6ビット）
の流れを汲む。当時のＡＤが12ビットだったからと言う理由もある。BCDなら3桁だね。
4ビットは4004に始まる十進1桁を表現出来るからだが、４で割り切れないコンピュータだと
ＢＣＤをパックするのに不便だからありえない。
その上、上位互換を作るなら倍倍にしないと不便だから4,8,16,32,64,128となるのは必然。
リレーの置き換えを狙ったMC14500持ち出すおば加算には理解出来ないだろうけどｗ >>508
頭悪すぎｗｗｗ
そんな理由でビット数が決まってる訳じゃないｗ
℃素人って想像で知ったかするんだなｗｗｗ レジスタ幅やアドレス、データバスの幅が決まる理由なんて一言も書いてないが。2^nの性質について説明しただけ。
自分の大発見が実は中学生にも笑われるレベルだったからって興奮するなよw >>505
> MC14500B持ち出して何が言いたいんだｗｗｗ
お前のバカさを言いたいだけ w
そもそもワード長が４の倍数でないマシンなんていくらでもあるし
https://ja.m.wikipedia.org/wiki/36%E3%83%93%E3%83%83%E3%83%88 >>511
単なる歴史的事実を知らない癖に知ったかしたいだけだろうにｗ
聞かれても無いのに>>507みたいな誰でも知ってるような事をしゃしゃり出て
書いちゃう辺りに性癖ｗがもろ出てて笑えるｗｗｗ >>512
で、それは今でも駆逐されずに主流なのかいｗｗｗ >>514
> 単なる歴史的事実を知らない癖に知ったかしたいだけだろうにｗ
お前のことな w >>515
安価もまともに付けられないのかｗｗｗ
それともわざと？ｗｗｗｗｗｗ >>513
なるほどBCDが4bit区切りが都合がいいからか。CPU設計者はたぶんそんなこと微塵も考えてないよ。
8bit=1byteが定着してそんなアホなこと考慮しなくても勝手にその制約満たされるからな。
それに32bitの次は36bitとか40bitとかありえないでしょ。上位互換関係なくセンス悪すぎ。
むしろデータバスの制約を考慮すると32bit、64bitが自然。SDRAMは64bit幅だから。
おまえコボラーだろ？ >>516
今でも駆逐されずに主流なのかい ⇒ 歴史的事実を知らないバカ
の流れも理解できてないのかよ w >>517
> それに32bitの次は36bitとか40bitとかありえないでしょ。
ありえないと、決めつけは良くないなぁ。
事実、NECのメインフレーム ACOSは36bit機だよ。 >8bit=1byteが定着してそんなアホなこと考慮しなくても勝手にその制約満たされるからな。
6ビットでなく8ビットが定着したのが4ビットの倍数だから。
>CPU設計者はたぶんそんなこと微塵も考えてないよ。
だから知ったかすんなってｗｗｗ
Hキャリービットは誰が作ったんだよｗｗｗ 36は４の倍数じゃ無いとかｗ
ID:8R89zE+Gってアホだな。 >>507
DSPだと24bitとか48bitとか56bitとか。 >>517
SDRAMが64bit?
モジュールの話？ >>522
リンク先も読めないバカ w
より小型のマシンは18ビットワードを使用し、ダブルワードが36ビットとなった。
PDP-1/PDP-9/PDP-15
EDSAC は17ビットを「短語（short word）」、35ビットを「長語（long word）」とする、これと似たアーキテクチャであった。 >>512を読み返せば読み返すほど
ID:8R89zE+Gの馬鹿さ加減で笑えるｗｗｗ >>517
もう一つ、インテルが32bit延命の為にIAｰ32に導入したのが36bitアドレッシング。
ただ使われる様になる前に、AMD x64アーキがメジャーになってしまい、黒歴史になったw
> むしろデータバスの制約を考慮すると32bit、64bitが自然。SDRAMは64bit幅だから。
それはDIMMの規格であって、SDRAMのバス幅ではないよ。
SDRAMそのものは未に8bitと16bit幅。
グラフィクスになると、3色だから親和性がいい24bitが基本。 >>520
やっぱりでたなCOBOL専用機。
現行機が36bitじゃないってことはやはりセンスが無かったんだよ。
そもそもそんなセンスがないもの作れるってことはすべて独自仕様カスタムみたいなもの。
標準化された規格がない時代だからできること。制約が要件のみの開発。 >>527
言い返せなくてバカとしか言えなくなったのか w
哀れだな >>528
グラフィクスでもCPUバスに合わせる為に8ビットアルファチャネルを追加して
３２ビットにしたりするけどな。
そもそもグラフィック自体、各色16ビットとか浮動小数点で扱う時代になって来たし。 >>528
PenProの頃だから延命じゃないし、PAEは今でも使われてるよ。nxビット使うときはPAE必須だし。
おれも未だに32bitOSで32GBメモリ積んで使ってる。
amd64もPAEを多段に拡張してそのまま使ってるから、PAEオンにしないとlongモードには移行できない。 >>533
あや、そんなに古かったんだ。
これは俺の認識間違いだわ(汗) 映画なのですが、集団ストーカー・電磁波犯罪被害の内容にそっくりです。
暇があったら、見て下さい。
クリープゾーン : マインド・コントロール
https://www.amazon.co.jp/dp/B0000ESKVY/ref=nosim/?tag=nicovideo07_st1-22&;creative=380333&creativeASIN=B0000ESKVY&linkCode=asn&ascsubtag=7_vi_B0000ESKVY_sm7584036_u!OBx1[[HcA]_1471948674_a08163 今の32bitのUbuntuはPAE必須だな
Windowsと違って32bitでも4GB以上のメモリを扱える
Linuxはカーネルでドライバを用意してるのでそれができる
デスクトップ向けのWindowsがPAEにフル対応しなかったのは
ドライバもPAEに対応しなければ4GB以上のメモリを扱えなかったからだろう
今の64bit Windowsの普及を考えればマイクロソフトの判断は正しかった Macは8G、16Gと際限なくメモリを増やしちゃうけど、なんかWindowsは4Gでいいや、とそのままだな。 メインメモリ6GBのスマホ
64bitに移行して正解だった
最上位モデルは6GBメモリ搭載、6.8型モデルも――
ASUS、「ZenFone 3」シリーズ3機種を発表
http://www.itmedia.co.jp/mobile/articles/1605/30/news144.html ワード長を9bitの倍数にしとくとパリティとか色々と使えて便利〜 Pythonだとちょっとした計算プログラムでも64bit版の方が1.5倍くらい速い
Pythonだと64bitの方が有利
Pythonは整数型が多倍長演算だからなのかな 4倍精度浮動小数点演算は64bitの方が32bitより倍速い
桁数の多い演算は64bitの方が有利 > 4倍精度浮動小数点演算は64bitの方が32bitより倍速い
4倍精度浮動小数点演算の速度が性能に影響するような用途なら
ソフト演算なんかせんだろ。 そもそも、32bitのARMの場合、
gccが4倍精度浮動小数点演算に対応してないけどな
64bitのARMのgccはソフト演算の4倍精度浮動小数点演算に対応してるけど >>547
正しくは、ゆとりおっさんだから
おこちゃまよりずっとたちが悪い なぁ、人工知能の1ニューロンって1bitに対応するの？
64bitなら64ニューロン分を一度に処理出来るの？ むりやりそうやって関連付けできるだろうけど、普通はしないしbitとニューロンは対応しない >>552
そっか〜
いやさ、スマホ／タブレットに64bitは必要かで荒れた訳だけど、今の使われ方では必須では無いと思う。
でも、A.I.が搭載が進んだら必要かもと思ってさ。
サーバーで処理するのか、手元で処理するのか、見通せないけどさ。 >>554
512GFLOPS‥
浮動少数点演算を速くしたかったのなら、このアプローチはしないだろうに。 1coreの速度ではハナから勝負しないってことだな。あとはfpgaがどれだけ使いやすいか。 CPUはオンダイキャッシュメモリー増やしてるトランジスタ数の余裕があるなら
汎用レジスタもっと増やした方が良いんじゃね？
キャッシュメモリの容量に比べたら64bit256本とか楽勝だろ >>557
レジスタを増やすとなるとレジスタ指定のbit数も増えるから、命令セット全体を見直さないと無理。
32bit長命令を維持するならレジスタ指定で増えた分の命令を削らないといけない。
現に32bit→64bitでレジスタ本数が倍増したため「条件付き実行」が大幅に減らされてる。 >>557
中の人は既にやっていると思うよ。
見掛けレジスタは増やさずとも、レジスタ・ウィンドウで大量のレジスタを扱えるから。
命令セットの変更の必要も無いしね >>557
コンパイラなんかの研究だと、
レジスタ多くても、ループとかで頻繁に参照されるのはせいぜい十数個で
後はテンポラリとか、まぁ、どうでもいい値が入ってたりする物なんだとさ
それにレジスタ多すぎても、スレッド切り替えとか遅く… 結局、最初からRISCにするよりCISCを頑張ってRISCにした方が性能が上がるって事だな。 >>561
>CISCを頑張ってRISCに
インストラクションを頑張って変えるのか・・・ >>561
RISCもガンガンと命令増えているけど、RISCとAMDに危機感を感じたintelが頑張った結果。
その考えは短絡的でない？
Atom、どうなるんだろう。
タブレット市場は諦めるのかな。 ARM版Windowsが全く売れなかったんだから拘ってるのはユーザー。 >>564
昔は拘っていなくて、最近は拘っているかも。
その昔はi960?を出したし、その前は286の陰に別プロセッサがあったと記憶。
ただx86のソフト資産をひっくり返せなかった。
64bitはIAｰ64をすすめたが、これもx64に負けた。
x86からの乗換えに負け続けた結果が今。
唯一成功してたXscaleを手離したのは謎。 そもそも箱の中身がIntelだろうがARMだろうが客にとってはどうでもいいこと
(そもそも普通の人間はCPUの存在自体理解してないし)
致命的なのはウィンドウズ従来のソフトが動かない ただそれだけ 何十年もCMしてんだからインテル入ってるぐらい普通の人でも知ってるわ。
それに比べてARMの知名度は一般にはゼロに等しい。最近ハゲ関連で始めて知った人も多いだろう。 ウィンテルは既存のソフトウェア開発者向けにシステムを構築し
新しいソフトウェア開発者向け開拓をしようとしなかった
今は新しいソフトウェア開発者開拓に頑張ってるが、、、 ARM 激安
x86 割高
Android 開発無料
Windows 開発高価
シェア広げるのは簡単
安くすりゃいい
勝手に人が寄ってくる
そういう環境で
どうやって利益をあげるか？
経営者の手腕 >>571
> Android 開発無料
> Windows 開発高価
それ、ここ電気・電子板ネタか?w
> ARM 激安
> x86 割高
そうでも無い。
TIが出してる64bit ARMのフラッグシップデバイスは10万超えるよ。 >>572
タブレット用のatomは無料だったらしいしな。 winの開発は今となっちゃ無料だろ
逆にARMなんか、ほぼデフォルトのkeilなんて個人じゃ買えんわw × TIが出してる64bit ARMのフラッグシップデバイス
〇 TIが出してる32bit ARM＋DSPのフラッグシップデバイス
DSP入りで純粋なARMでひ無かったでござる(汗) >>573
そうだったんだ。
WinRTが普及する事を、期待してたんだけと。 追記機能てんこ盛りの今のARMは今のx86よりはるかに汚い。 >>577 >>578
DSPは、普通のx86用途には出てこないから。
そんな用途がx86より限られるデバイスで10万超えると主張しても、我ながらアホだと思ってねorz
ただその路線でいいなら、ARM入りのFPGAは50万超えるのがあるし。 >>583
そうかもね。
出来るかどうか知らないけど、x86をSMPでなくAMPに構成して、各コアに処理を割り当てれば速いかも。 >>583
そうかもね。
出来るかどうか知らないけど、x86をSMPでなくAMPに構成して、各コアに処理を割り当てれば速いかも。 >>586
DSPだとキャッシュをSRAMとしてコードを詰め込んで、レイテンシーが定かで無い外部メモリを使わない構成が出来る。
余計な事は一切せず、ひたすら数値演算に専念させる構成。(普通のCPUとして、勿体なく使う構成もあるけど)
なのでDSPをブン回すには、CPU(ARM)で面倒見ないといけない。
その点x86は、キャッシュをメインメモリとして構成出来るのかな？
とにかくこの世界だと、ソフト屋さんはガリガリと速度を追い求める。 DSPのプログラムなんて短いから４Mバイトもあるキャッシュに全て収まる。
バタフライ演算用のアドレッシングが用意されてない位で特に問題なく使える。 >>588
それはそう。
でも、フラッシュされれない保証無いし。
ところでCortexｰM3より上位にはDSP命令があった筈だけど、CortexｰM3で固定少数点演算をガシガシやっている人はいるのかな? >>589
>でも、フラッシュされれない保証無いし。
いや、普通にキャッシュ制御すれば良いだけ。 M3でもクロックとフラッシュの速度にもよるけど128kbps/44.1kHzのmp3ソフトデコードとか出来て楽しい わざわざ効率の悪い、苦手なことをさせて楽しいとかMすぎる。 >>594
効率悪いかな？
デバイスの限界まで性能を引きだす、楽しいじゃん。 >>597
限界(ノーウェイト)までキッチリ回して仕事を片付け、後はスリープするのが最もエコ >>594
趣味だからだろ。
趣味なら最適なものをその都度選ぶなんてできないからな
業務でmp3ソフトデコード再生するなら、M4Fぐらいを選択して最適な構成(内蔵DACより音が良いオーディオ用DACアウトとか)に
したのを設計するんだろうが。 自分でゴリゴリすると思わぬ発見があったりするからなぁ… x86でmp3をソフトデコード出来るのって486DX位だったな確か 仕事ではDSP処理を普通にしていると思うけど、お前らってどんなDSP処理を書いている？ > 仕事ではDSP処理を普通にしていると思うけど、
狭い世界に生きてること自覚しろよ ■ このスレッドは過去ログ倉庫に格納されています
