いてつくブログ

2ちゃんねるのスレッドをコピペしてまとめてみるブログ

コンパイラ

PC等【C++】高速化手法【SSE】

1 :デフォルトの名無しさん:2005/10/27(木) 02:55:36
C++やインラインアセンブラ、SSEなどによる高速化の手法
について語りましょう。

178 :デフォルトの名無しさん:2009/01/07(水) 23:00:55
メモリ(バキューン!)とかを考慮すると構造体より配列のほうが高速?

179 :デフォルトの名無しさん:2009/01/08(木) 00:02:43
>>178
同じ。

185 :デフォルトの名無しさん:2009/01/09(金) 14:29:17
>>179
うほ?
>>178の意味がいまいち分からんが、
char array[0x100];

struct{char value;} array[0x100];
だったらレジスタサイズにパディングされる分、構造体の方が早くね?
ちなみに、同じ事だが容量気にして構造体のなかでshortとか使うと
パデイング入るんでメモリに無駄が発生する。
まぁ、パディングを知っていれば無駄を防ぐこともできるけど。

189 :デフォルトの名無しさん:2009/01/11(日) 01:50:19
>>185
> struct{char value;} array[0x100];
> だったらレジスタサイズにパディングされる分、構造体の方が早くね?

pragmaやattributeでパックしない限りpaddingは入らないだろ。

191 :,,・´∀`・,,)っ-●◎○:2009/01/11(日) 06:05:36
>>189
構造体やその配列の場合、パディングが入る。
デフォルトが4バイト単位だったかな?

360 :デフォルトの名無しさん:2009/09/08(火) 20:07:19
だんごじゃないけどi5はi5だよ。それ以上でもそれ以下でもない。

361 :デフォルトの名無しさん:2009/09/08(火) 20:13:34
>>360
おめーみたいなカスには聞いとらん失せろゴミが
ダンゴさんマダー?

363 :デフォルトの名無しさん:2009/09/08(火) 21:25:40
>>361
ちょwだれww
ほれ、なんかcore2の時とかこれはいいぜーとかなんか詳しく言ってたような気がしたから
i7なりi5なりのアーキテクチャ面からの意見を聞いてみたかったんだ

382 :デフォルトの名無しさん:2009/09/10(木) 00:35:11
おい!テーブル使わん言ったじゃねえかよ。氏ねカス。

387 :デフォルトの名無しさん:2009/10/08(木) 03:33:43
unsigned int mod6(unsigned int m){
unsigned int a = 0;
static unsigned int x[] = {0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4};
__asm{
mov eax, m
test eax, 1
jz Mod3
inc a
Mod3:
shr eax, 1
lea ebx, x
mov edx, eax
and eax, 0000ffffh
shr edx, 16
add eax, edx
mov edx, eax
and eax, 0000003fh
mov ecx, edx
and edx, 00000fffh
shr ecx, 12
shr edx, 6
add eax, ecx
add eax, edx
mov edx, eax
and eax, 0000000fh
shr edx, 4
add eax, edx
mov edx, x[eax*4]
add a, edx
}
return a;
}

399 :デフォルトの名無しさん:2009/10/08(木) 15:58:42
逆数乗算で商を求めて元の値から引いたほうが速い
今のCore MAでは整数乗算は浮動小数除算機と兼用してて
非除数 - (除数×小数点以下切り捨てた商)

まあベンチ取ってみればわかるがコンパイラの吐くコードにも勝てんと思う

401 :デフォルトの名無しさん:2009/10/08(木) 17:45:39
static??const??int??rcp6??=??1.0??/??6.0??*??std::pow(2.0,16.0);
int??x??=??255??-??((255??*??rcp6)??>>??16)??*??6;

確かにこれで十分な気がするし、>>387より速そうだ。


414 :デフォルトの名無しさん:2009/10/09(金) 01:24:41
>>387
inline unsigned int mod6(unsigned int a){
 unsinged int b = (a >> 3) + (a >> 5); // /6
 unsinged int c = (b << 1) + (b << 2); // *6
 return a - c;
}

456 :デフォルトの名無しさん:2009/10/22(木) 03:07:47
C/C++でメモリプール(int, doubleなど様々な型が共存)を作り、
メモリプール内部でメモリの詰め直しを行って最適化しようと試みています。

入門書+α(boostがわかるぐらい)なので、
キャッシュやメモリに関する特殊なことは全然わかりません。
何か気をつけなければならないことや忠告があれば教えてください。

488 :,,・´∀`・,,)っ-○○○:2009/10/28(水) 04:46:10
for (i = 0; i < N; i+=4) {
  sum1 += A[i];
  sum2 += A[i+1];
  sum3 += A[i+2];
  sum4 += A[i+3];
}
sum = sum1 + sum2 + sum3 + sum4;

っていうか組み込み関数使えよ

498 :デフォルトの名無しさん:2009/10/29(木) 08:44:26
>>488
これってNがわかっていないとコンパイラはやってくれないよね?
ICCだと出来るのかな?
GCCではベクトル化してくれなかった。

539 :デフォルトの名無しさん:2011/01/28(金) 11:43:56
x86は浮動小数点が弱くて仕方がないからなあ
8087のコプロセッサの頃からの負の遺産を引きずっている
でもL1/大容量L2キャッシュを媒介にする事によって相当克服して来てはいるんだけどな
PowerPCなどにどうしても勝てない

596 :デフォルトの名無しさん:2011/05/30(月) 10:20:14.97
結論から言うとメモリの転送がボトルネックです。
書き出しのアライメントを揃える事とstreamを使う事で何割かは改善出来ますが、基本的に速く出来ません。

最適化とは遅い部分を探し出す事に他なりません。
安直にSSEとかマルチプロセッサにしようと思わず、真にボトルネックを見つけられるようになりましょう。

真に遅い部分が分かったなら、平均化フィルタと何が違うのか、どうしてもう速く出来ないのかが理解出来るようになります。

598 :デフォルトの名無しさん:2011/06/13(月) 15:11:06.75
>>596
メモリの転送がボトルネックなのか、演算部分がボトルネックなのかは
どうやって判断すればいいのですか?つまりどこを見たらよいのか。
あるいはあなたはどうやってますか?
ツールとか使うのでしょうか?

618 :デフォルトの名無しさん:2011/07/02(土) 22:44:49.03
mapの方がアライメントされてないんじゃない?

619 :デフォルトの名無しさん:2011/07/02(土) 23:38:54.68
std::pair<int, hoge>からaligned_stl::pair<int, hoge>へのコードがバグってるんじゃないの

620 :618:2011/07/03(日) 00:21:26.44
適当な事書いたと思ったけど、std::mapにカスタムアロケータでいけるっぽい
http://ideone.com/sOWl6



621 :デフォルトの名無しさん:2011/07/03(日) 02:45:36.94
>>618
mapの方は、__declspec(align(16))みたいなことはしてませんが
カスタムアロケータを渡しており、カスタムのpair(aligned_stl::pair)を使うように指定してます。

>>619
わかりづらくてすみませんorz
std::pairは一切使っておらず、aligned_stl::pairのみです。
make_pairもaligned_stl::pairを返します。

>>620
ありがとうございます、Win7 64bitのVC2008Expressで動かしてみましたが
カスタムアロケータのc.insertで、Hoge()の引数なしのコンストラクタで落ちます(x_ = static_x)
Hoge hoge;
c.insert( ::std::make_pair<int,Hoge>(i, hoge) );
とやると、make_pairのところのコピーコンストラクタで落ちます( x_ = src.x_)。
なので、前回書いたのと同様に
Hoge hoge;
std::pair<int, Hoge> pairArg(i, hoge);
とやってからpairArgを渡すと落ちませんでした(c.insertのみ。d.insertは落ちる)。

どうもpairに関してはアラインメント指定しなくても、中のメンバが
アラインメント指定されていれば問題ないようですね(アロケータだけでよい?)。
もうちょっと試してまた報告します。
ただ、2008だとアラインメント指定が一時オブジェクトに対して効かないと考えたほうが
いいのかもしれませんね(´・ω:;.:...  (インライン展開された場合は除く)
ありがとうございました。

638 :デフォルトの名無しさん:2011/07/05(火) 22:56:13.54
余分なカッコが多すぎるコードってみにくくて嫌いだ。

if (a == 0 && b == 0 || c == 0 && d == 0)

if ((((a == 0) && (b == 0)) || ((c == 0) && (d == 0))))

この二つだと上の方がはるかに見やすいと個人的には思うが、
見やすさを優先してカッコをつけるとか言って下のように書く人がいる。


649 :デフォルトの名無しさん:2011/10/10(月) 19:26:30.72
指定桁数で四捨五入する以下の関数の実行速度を上げたいの。
(valueは0~9999、digitsは0~5が保証される)
SSE使って高速化頼む。

double NormalizeDouble(double value, int digits) {
  static double t0[] = { 1, 10, 100, 1000, 10000, 100000 };
  static double t1[] = { 1, 0.1, 0.01, 0.001, 0.0001, 0.00001 };
  return (int)(value * t0[digits] + 0.5) * t1[digits];
}

652 :デフォルトの名無しさん:2011/10/10(月) 19:49:57.12
>>649
最適化スレで終了宣言してからにしろよ

653 :デフォルトの名無しさん:2011/10/10(月) 19:50:50.26
でもベクトル化で少しは早くなるわよ

664 :デフォルトの名無しさん:2011/12/17(土) 22:41:12.80
signed shortの配列に
floatもしくはdouble型の乗算をして
クリップ処理をほどこし
signed shortの配列に戻すのを
SSEにしたいのでやってください


これ

signed short s[100];
float f
init a;

for (a=0;a<100;a++)
s = s[a] * f;

665 :デフォルトの名無しさん:2011/12/17(土) 23:06:34.33
それ、どう考えても実数型⇔整数型のコストがでかすぎる。
たった100件でいいなら実数で持てないの?

679 :デフォルトの名無しさん:2011/12/19(月) 02:15:44.43
初めてSSEに触れるので、まずは簡単なコードを作成してみたのですが、
SSEを使わないほうが40倍も速いという驚愕の結果が出ました。
何が間違っているんでしょうか??

コンパイラ:VC++2005(Releaseモード、浮動小数点モデル:FAST)

float* f4pakAdd( float* pfA, float* pfB )
{
  _declspec( align( 16 ) ) static float fC[ 4 ];
  
  _asm
  {
    mov ebx, pfA
    movaps xmm0, oword ptr [ebx]
    mov ebx, pfB
    movaps xmm1, oword ptr [ebx]
    addps xmm0, xmm1
    movaps fC, xmm0
  }
  
  return fC;
}

呼び出し側

for( int i = 0; i < 10000000; i++ )
{
  pfC = f4pakAdd( fA, fB );
}

682 :デフォルトの名無しさん:2011/12/19(月) 02:34:54.14
パイプライン化したコードでもないし、スタックチェックが行われている気がするが。
逆アセ確認したかい?

707 :デフォルトの名無しさん:2011/12/23(金) 11:26:47.88
どんな変数も問答無用でアライメント16にするようにコンパイルする設定があれば
面倒な記述を減らせると思うんですが、何かデメリットあるんでしょうか?
メモリの隙間ができて勿体無いとかあるかもしれませんが、メモリ量の多い昨今、
それほど問題にならないのでは?と思います。
むしろアライメントすることでメモリアクセスの冗長さを減らせて帯域を節約する効果も
あって一石二鳥ではと思うんです。

708 :デフォルトの名無しさん:2011/12/23(金) 11:59:03.43
gccだと-mpreferred-stack-boundary=4がデフォルトだから既に16バイトアライメントだよ
構造体の詰め物は互換性もあるし難しいじゃないか

710 :,, ・´ ∀ `・ ,,)っ-○○○:2011/12/23(金) 12:41:37.02
>>707
なにそれ君いまだにPS3向けのゲームとか組まされてるわけ?

711 :デフォルトの名無しさん:2011/12/23(金) 15:57:24.48
>>708
glibcのmallocは8バイトだよ

>>710
SandyBridgeでもアラインメント取れてないと遅いでしょ

713 :デフォルトの名無しさん:2011/12/23(金) 17:19:17.60
>>711
Nehalem以降はmovups/dquもペナルティ無く使えるでしょ
まあ結局Core2以前も考慮するとコード振り分けるから労力は変わらないのだけれど...

714 :707:2011/12/24(土) 02:12:26.59
すみません、自分は日曜プログラマレベルで、対象CPUはx86、環境はVC++です。
VC++の設定を見ていると、「構造体メンバのアライメント」というのがあって16バイトアライメントを選べるようになってました。
同様に通常の変数もアライメントできる設定があるかと思い探しましたが見付かりませんでした。

715 :デフォルトの名無しさん:2011/12/24(土) 02:18:17.32
どう考えてもこれ以上削れないってくらいの手書きインラインアセンブリコードに対し、
C記述版をVC++のReleaseモード(最適化O2)でコンパイルしたもののほうが1.3倍速かったです。
生成されたアセンブリを覗いてみたところ、

変数 * 3

というコードを

lea edx, DWORD PTR [eax+eax*2]

としていてびっくりしました。
これって、アドレス演算を行うローダ(専用の演算器?)を使うことで、
通常のALUと並行して演算(スーパースカラって言うんでしたっけ?)し
高速化しているということなんでしょうか??

716 :デフォルトの名無しさん:2011/12/24(土) 02:34:46.72
>>714
__declspec(align(N))

717 :707:2011/12/24(土) 02:44:05.59
>>716
ありがとうございます。
それは知っているんですが、>>707でも書いた通り、
そういった記述をわざわざせずとも、自動で全てアライメントしてくれるような設定があればイイのでは?
と思った次第です。

しかし、上でも仰られたように、互換性の問題があったりで難しいのでしょうね・・・
でも二重インクルード防止の「#pragma once」のように、互換性を考慮しない機能があったりするくらいですから、
自分のようにずっとVC++しか使わない人間を対象にそういうオプションが用意されていても良いのではと思いました。

733 :デフォルトの名無しさん:2012/03/09(金) 12:53:25.77
unsigned int maxpos(unsigned int src[256])
{
unsigned int i, m = 0;
for(i = 1; i < 256; i++)if(src[m] < src[i])m = i;
return m;
}
これをSSEで高速化する方法があれば教えて下さい

739 :デフォルトの名無しさん:2012/03/11(日) 00:41:15.69
>>733
画像とか統計の基礎だな。疑似コードで書くとこんな感じだ

maxpos(src[256]) {
pos = {0, 1, 2, 3};
for(i=0; i<256; i+=4) {
 s=load(&src[i]);
 isGT=maxVal<s;
 maxVal=isGT&s | ~isGT&maxVal;
 maxPos=isGT&pos | ~isGT&maxPos;
 pos += 4;
}
return max_position(
 maxVal[0], maxPos[0],
 maxVal[1], maxPos[1],
 maxVal[2], maxPos[2],
 maxVal[3], maxPos[3]);
}

762 :,, ・´ ∀ `・ ,,)っ-○○○:2012/03/14(水) 07:23:58.09
packed unsigned intの比較(マスク生成)だけど、両項のMSBを反転してからpcmpgtdするより
psubd + psradのほうが速いかもしれない

768 :デフォルトの名無しさん:2012/03/21(水) 23:53:20.16
P6,P2,P3,P4はforwardならnot taken backwardならtakenがデフォルト
P4はPrefixでヒントを出せる
PM,Core2はランダム
ソースはAgner

775 :デフォルトの名無しさん:2012/03/24(土) 21:41:50.71
そう思ってくれるのはいいが、間違いの指摘と
実際はどうなってんのか答えてくれ
批難だけの回答はいらん。

778 :デフォルトの名無しさん:2012/03/24(土) 21:52:06.49
>>775
じゃあ間違いを指摘してやる。

>大概returnやthrowが行われるからifをすっ飛ばせば速いのは解る。
前方への条件分岐は、「分岐しない」と予測される、とオマエ以外の全員が言っている。
if (xx) return
で「すっ飛ばせば云々」なんて、理解していないまま「わかったつもりになってるだけ」の証拠。

>今のCPUは分岐ヒントとか投棄とかあって単純じゃないんだろ
ヒントはともかく、投機はまさに「投機実行するために分岐予測をする」のであって
「投機実行もあるから分岐予測が複雑になる」はナンセンス。
もちろん、エンプラ系/VLIW系では「分岐の有無の両経路を実行する」なんてのもある(らしい)が
一般的とは言いがたい。

779 :デフォルトの名無しさん:2012/03/24(土) 21:59:34.64
>>778
内容じゃなく国語的に誤解されてるな。

>前方への条件分岐は、「分岐しない」と予測される、とオマエ以外の全員が言っている。
if( xx ) throw xxx;
throwなんて実行するケース殆ど無いんだから基本if実行しないってのは同じ話。
矛盾してないでしょ。

まず分岐予測が複雑になってるって話はしてないよ。
投棄実行については投棄実行を考慮した上での静的予測方法があるでしょという話。

780 :デフォルトの名無しさん:2012/03/24(土) 22:04:11.41
>>779
だから、ifの内部は「実行すると予測される」んだよ、バーカ

782 :デフォルトの名無しさん:2012/03/24(土) 22:06:41.25
せめて正しい漢字使えよ。

一度なら単なる変換ミスとして納得できるけど
繰り返しているってことは、別の意味に捉えているとしか思えない。

783 :デフォルトの名無しさん:2012/03/24(土) 22:09:32.88
>>780
お前バカだろ
みんなアセンブリ前提で言ってんだよ

jze label   if() {
・・・処理・・・
labeli     }


789 :デフォルトの名無しさん:2012/03/24(土) 22:48:33.55
投棄実行については誤解してたわ。
2つの分岐を両方実行して実際実行対象にならなかった方の結果を破棄するものだと思ってた。

792 :デフォルトの名無しさん:2012/03/24(土) 23:01:04.27
一応。

突然returnやthrowが出てくるのが
if (xx) return
という意味じゃないか、というのも勝手に俺が頭の中で補って想像しただけで
実際には何の説明も無く(ifの多くがreturnやthrowというのにも同意しにくい)
唐突な「rerturnやthrow」「すっ飛ばす」を必死に理解しようとしたのがそもそもの間違いかもね。

794 :デフォルトの名無しさん:2012/03/24(土) 23:04:39.09
>>792
>>779で補足だしてるだろしつこいわ

803 :デフォルトの名無しさん:2012/03/25(日) 16:12:43.94
インテルの最適化マニュアルだと
>インテルPentiumM??プロセッサー、インテルCoreSolo??プロセッサー、インテルCoreDuoプロセッサーは、
>ジャンプの向きに従った条件分岐を静的には予測しない。これらのプロセッサーでは、
>すべての条件分岐は、最初に発生したときでも動的に予測される。
と書いてあって、wikiで調べたらPenM以降は広域分岐予測を取り入れた関係で静的予測はしなくなったみたいだね
http://ja.wikipedia.org/wiki/%E5%88%86%E5%B2%90%E4%BA%88%E6%B8%AC

>>768
>PM,Core2はランダム
というよりも、「前に実行した別の分岐命令の結果も影響する」とした方が適切みたいだ

分岐予測に関して
http://news.mynavi.jp/column/architecture/index.html
の第167回からの解説が参考になるよ



http://toro.2ch.net/test/read.cgi/tech/1130349336/l50/../人気ブログランキングへ

PC等新C言語を作ろう

1 :デフォルトの名無しさん:2007/07/21(土) 18:27:03
これまでの古いC言語から新しいC言語を作りましょう。
C言語に足りない、欲しい機能を追加して最終的には標準化しましょう。

いまここに新C言語作成委員会の発足を宣言します。

とりあえず必要と思われる機能は
・クラス
・テンプレート
などでしょうか?

4 :デフォルトの名無しさん:2007/07/21(土) 19:39:27
コンパイラ誰が作ってくれるんだよ

110 :デフォルトの名無しさん:2007/07/28(土) 18:05:58
前方参照が欲しいなぁ。

121 :名無しさん@そうだ選挙に行こう:2007/07/29(日) 06:08:46
>-前方参照(>>110)

これってどういうの?


124 :110じゃないけど:2007/07/29(日) 18:02:20
>>121
後ろで宣言したものでも使える。後方参照とも言う。
Dの例(前方参照あり):
void foo(){
?? bar();
}
void bar(){
}

Cの例(前方参照無し):
void bar(void);
void foo(void){
?? bar();
}
void bar(void){
}

129 :デフォルトの名無しさん:2007/07/29(日) 21:11:10
>>124
「後ろで宣言した」と言うのが間違い。

コンパイラは「ソースを読み進めて行く」んだから、
ソースの下のほうが「前方」だよ。

勘違いしている人が多いので、後方参照とか書いてあるバカ本があったりする。

131 :デフォルトの名無しさん:2007/07/30(月) 00:29:29
へー、そういう解釈の一派もあるんだ…

133 :デフォルトの名無しさん:2007/07/30(月) 22:13:52
>>131 バカ本著者乙 (w

134 :デフォルトの名無しさん:2007/07/31(火) 00:32:44
>>133
誤爆?

135 :デフォルトの名無しさん:2007/07/31(火) 01:22:21
まともに(?)煽っていて誤爆に見えないが。

136 :デフォルトの名無しさん:2007/07/31(火) 01:42:48
まともには見えないが。

138 :デフォルトの名無しさん:2007/07/31(火) 11:44:19
>>133 を読むのに知識が必要とは思えないが。

140 :デフォルトの名無しさん:2007/07/31(火) 12:51:57
>>135 が言っているのはこういう事でしょ。

1. >>133 は煽っている
2. >>133 の煽りは煽りとしては特に不可解な所は無い
3. よって >>133 は誤爆ではない

俺は >>133 は煽りとして不可解だと感じたから、誤爆だろうと思った。
あまり知性も感じられない書き込みだし、よく誤爆する人間なんだろうと。

142 :デフォルトの名無しさん:2007/07/31(火) 14:43:20
単に136が135の「まとも」の使い方を誤読しただけ

143 :デフォルトの名無しさん:2007/07/31(火) 20:38:33
>>142
>>140>>135 の意図した事と異なるのであれば、
>>135 がまともな日本語でないのが原因だよ。
まともに相手してあげた俺がバカだったみたいだね。

145 :デフォルトの名無しさん:2007/07/31(火) 21:36:34
いちいち阿呆とか馬鹿とか付けないと文章書けない人か

146 :デフォルトの名無しさん:2007/07/31(火) 22:05:24
C言語はハードに近い部分を記述することができますが
最近の言語では、それは無くなってきていますね。
良いことか分かりませんが。

147 :デフォルトの名無しさん:2007/07/31(火) 22:20:59
>>131=>>134=>>136=>>138=>>140=>>143=>>145 自演乙

148 :デフォルトの名無しさん:2007/07/31(火) 22:23:57
>>146
> 最近の言語では、それは無くなってきていますね。

FORTRAN の時代からハードに近い部分は高級言語では書けなかったけど?

151 :デフォルトの名無しさん:2007/07/31(火) 22:49:24
>>147は自分が正しいと思ったら絶対曲げないタイプでしょ?


152 :デフォルトの名無しさん:2007/07/31(火) 23:37:04
OS が書ける言語ならハードに近い部分も書けるんじゃないのかな。
Pascal, Oberon, Lisp, Smalltalk, C++, etc...

159 :デフォルトの名無しさん:2007/08/01(水) 21:49:59
>>151
間違ってると言うなら、ソースつきで反論どうぞ。
バカ本はダメだよ。(w

>>152
Pascal と Lisp には標準ではハードを直接触る機能はないと思ったけど。

Oberon, Smalltalk は使ってことないからよくわからんが。

160 :デフォルトの名無しさん:2007/08/01(水) 23:22:13
頭固い奴だな
OSのアセンブラコードを吐くプログラム書けばいいじゃん

161 :デフォルトの名無しさん:2007/08/01(水) 23:27:30
それを実行時にやるというなら、生成したコードを実行するために、
任意のアドレスへジャンプもしくは関数呼出などができる機能を
持っている必要があるという制約が生じるね。

172 :デフォルトの名無しさん:2007/08/04(土) 22:25:25
以上、言い負けてから先が威勢の良い典型的な厨房でした。

174 :デフォルトの名無しさん:2007/08/05(日) 10:43:00
>>172-173
> 典型的な厨房でした。

反論できないから、人格攻撃か。
わかりやすい奴だな。

> 簡単な技術の話も出来ないなら他所へ行ったら良いのにな。

で、おまえ等 (一人かも知れんが) のレスのどこに技術の話があるんだ?

反論したければ、単に >>129 の解釈に対する反例をあげれば済む話なのに
できないからうだうだ言ってるんだろ?

175 :デフォルトの名無しさん:2007/08/05(日) 11:17:42
そんな下らない事で息巻いてたのか…

176 :デフォルトの名無しさん:2007/08/05(日) 11:26:58
>>174
>で、おまえ等 (一人かも知れんが) のレスのどこに技術の話があるんだ?

俺じゃなくてさ、>>159 の書いてる事が素人っぽかったからね。
「Oberon, Smalltalk は使ってことない」らしいけど、Pascal と Lisp も
殆ど知らないんだろうなと思って。

177 :デフォルトの名無しさん:2007/08/05(日) 12:26:28
>>175
へ??、君はもっと凄いことについてレスしてるつもりだったんだ。
詳しく説明してくれるかな?

>>176
> Pascal と Lisp も殆ど知らないんだろうなと思って。

そう思うなら、どこか素人っぽいか指摘すればいいだけ。

指摘もできないから、「知らないんだろうな」とか言う技術的じゃ
ないことしか書けないんだろ?

# まさか、「OSのアセンブラコードを吐く」なんて言うわけわかめ
# のことを言ってた奴が絡んでるのかなぁ...。(w

178 :デフォルトの名無しさん:2007/08/05(日) 12:54:10
この人、リアルでは孤独なんだろうな。。


181 :デフォルトの名無しさん:2007/08/05(日) 13:02:52
"ハードに近い"の定義がされてないのに何この荒れよう。
人によってリアルモードのことだったり割り込みのことだったりしそう。
#リンカスクリプトを言語に統合まだー?

183 :160:2007/08/05(日) 13:15:35
>>177
「OSの」は余計って事か。ごめんね。
書いたときは>>152以前は読んでなかったから、OSでも書くつもりなのかと思ってたよ。
>>161には話通じてるみたいだし、スルーされたと思って放置してた。
どのみちファイルに出力できる言語なら何でもできるだろ、
って事を>>148みたいな人へ言いたかったんだけど。

184 :デフォルトの名無しさん:2007/08/05(日) 13:24:18
ホントにどんな事にでも噛み付いてくる奴は居るもんだな

185 :デフォルトの名無しさん:2007/08/05(日) 13:41:40
夏だからな

186 :デフォルトの名無しさん:2007/08/05(日) 13:50:23
>>178-180, >>184-185
「技術的に指摘して」って言ったらこの様ですか...。

まあ、>>185 が言う通り 夏 なんだろうな。

>>181
> "ハードに近い"の定義がされてないのに何この荒れよう。

まあ、最低限として任意のメモリの読み書きができないとダメだろうな。

て言うか、リアルモードとか割り込みなんて事まで言い出すと特定プロセサ
シリーズ専用の言語になるから「標準」でと言うのはないだろうな。

>>183
単に茶化しただけだ、気にしないくれ。

そもそも、>>160 の書き込み自体洒落 (=原理的には可能だけど、実施が
大変面倒なので実際的じゃないという意味) だろ?

て言うか、このスレ自体がネタスレだし...。

> どのみちファイルに出力できる言語なら何でもできるだろ、

>>161 が指摘してる通りそのファイルを実行する手段が必要。
標準の言語仕様としてその機能を持ってる言語ってそんなに多くないよ。

188 :デフォルトの名無しさん:2007/08/05(日) 14:09:42
>>186
各arch毎に言語拡張すれば良くね?

189 :デフォルトの名無しさん:2007/08/05(日) 14:37:07
>>186
言語仕様に含まれてなくとも、大抵は処理系毎にFFIとかが整備されてるもんだよ。
C言語にしてもasmは標準ではないし、C言語で適当なバイト列を関数アドレスとして
キャストして実行できたりするのも処理系が「たまたま」許してるだけ。
そんな所を君がごちゃ混ぜに語っているのが、分かってないのでは
と言われる理由かと。

190 :デフォルトの名無しさん:2007/08/05(日) 15:05:34
>186
>そもそも、>>160 の書き込み自体洒落 (=原理的には可能だけど、実施が
>大変面倒なので実際的じゃないという意味) だろ?

大変面倒というのは君の主観でしかないよね。
そういうのは一度作ってしまえばその環境で使いまわせるし、
やることも極めて単純な変換作業だよ。
エミュレータやコンパイラ作ったりする人なら普通に思いつく発想。
で、

>て言うか、このスレ自体がネタスレだし...。

このスレは仮にも「新C言語を作ろう」なんだから、その程度を、
大変面倒と言ってしまうレベルの人間の横槍は遠慮してもらいたい。

193 :>>187 かわいそう...:2007/08/05(日) 15:51:36
>>188
そう、実用的には処理系毎の定義と、何らかの言語拡張がなされているのが普通。

特に、ハード周りとかファイル関連はアーキテクチャやシステム毎の差異が大きいので
標準の言語仕様では定義してない方が多い。

C言語は、PDP + Unix と言うある意味特定環境用の言語として作られたから生い立ちと
して他の言語に比べてそこら辺の定義が比較的されていたんだ。

>>189 の言うキャストなんかも、アーキテクチャが決まっていたから許されていたが、
8086 + DOS みたいにメモリモデルによっては関数へのポインタとデータへのポインタで
ビット幅が違うなんて言う変態的なアーキテクチャだと破綻するので言語仕様からはず
されただけ。

>>189
そういう突込みを避けるために、わざわざ゛>>159 に「標準では」って
言う言葉を入れてあるんだが。

> そんな所を君がごちゃ混ぜに語っている

具体的に指摘よろしく。

>>190
まあ、ちょっと落ち着け。

そういう仕組みを作るのが面倒じゃなくて、単に「ハードに触る」だけで、ファイル作っ
てそれを実行して (必要に応じて結果を) 得るって言うことが面倒だ言ってるんだけど、
理解できてる?

216 :デフォルトの名無しさん:2007/08/25(土) 12:46:57
・変数スコープをなくし、全てグローバルとする。
スコープとはいわば開発者に脳内スタックの確保を一段
強要する機能であり、開発の邪魔である。
変数は全て設計者が関数一覧表とそれに付随する変数一覧表にて管理する。
ローカルだからと適当に変数を作り捨てるようなことをするから
ゴミ変数が増え、バグとなる。

・ポインタの廃止。ポインタは労多くして功少なしの典型機能。
・キーワードを全て大文字化する。小文字は小さく目に悪い。

252 :デフォルトの名無しさん:2008/07/24(木) 01:36:50
>>1
やる気があるなら、予約語を全部排除して、
全部自前で定義できるようにしてくれ。
そういう仕様なら乗ってやる。

303 :デフォルトの名無しさん:2009/06/18(木) 22:48:47
というかOSがかける程度に強力であり、
かつ高尚で可読性に優れたものが書けるならいうことなしだ

そうするとおもいっきりModula-2になるわけだが。

だからあのキモイbegin??end構文を{??}の構文にして、
コンパイラの実装がしやすく、またプログラミング初心者も覚えやすいような
簡潔な文法があればいい。
あとこれは個人的意見だけど、できるだけソースコードは短く書けたほうがいい。
じぶんのキーボードの打ち方が間違ってるのだろうけど、腱鞘炎になりかけたことがあるから。


334 :デフォルトの名無しさん:2009/07/14(火) 20:18:42
個人的な案。
c -> newC
= :=
== = or !!=
!= !=
< < or !>=
<= <= or !>
> > or !<=
>= >= or !<
要は、!に否定と言う意味を持たせるなら演算子そのものも否定できたらどうかな、と。
# !の多重を認め出すと、!!!!!!!!!!=なんて書けてしまうのは実は問題かもしれないw


385 :デフォルトの名無しさん:2009/07/18(土) 18:45:24
コンパイラ屋さんの俺が来ましたよ。
専門は最適化なのでそっちしか興味ないんだけど、簡単なCへのトランスレータくらいだったら作ってみようかな??

401 :デフォルトの名無しさん:2009/07/19(日) 04:25:40
それなら、とりあえず全変数は読み取り専用、書き換え可能な変数はmutable修飾子を付けるという方向にしよう。

403 :303 ◆pFphp4Ej4w :2009/07/19(日) 16:24:49
どうも。やっと模試が終わりました。死んだ…

>>401
なるほど。
それはprivate,public修飾子を残した上で付け加えるということでよいでしょうか?

この他「これがいやだからこうしてほしい」等要望をなんなりと。

それから、取りあえず「新C言語」の名前を決めたいのですが、なんかありませんか?(時期尚早と言うなら取り下げます。)

413 :385:2009/07/19(日) 18:36:40
そんじゃ夜から何か作り始めるよ。
実装言語はバリアントがあるOCamlとかの方が楽だけど誰でも改造しやすいようにJavaとかにしたほうがいいのかな?

>>403
とりあえず名前だけでも決めてくれると嬉しい。

447 :デフォルトの名無しさん:2009/07/20(月) 08:42:20
もうさ、Javaにポインタ付けて
ネイティブに対応させればいいんじゃない?

Javaの良さは、javaDocだと思うけどな

524 :デフォルトの名無しさん:2009/07/24(金) 23:56:47
303が何をしたいのか判らない
つまり提案しようがない
テンプレつーか一度方針をまとめてくれ

526 :デフォルトの名無しさん:2009/07/25(土) 00:14:45
自分が実装できそうな手軽な範囲だと、ヘッダファイルを無くしたいのと、マクロを改良できるならしてみたいです。

まずはCへのトランスレータしか考えてないのでランタイムが必要な機能は無理です。

それから型推論とかですかねー

546 :303 ◆pFphp4Ej4w :2009/07/25(土) 18:28:39
> 好き勝手言ってるだけだから、それらをぜんぶ取り入れたら無法地帯になるよね。

あぁ…それ忘れてた(;´д`)

> そうじゃなくて、周りの意見を聞いたうえで??「さて何を取り入れようか」??を??303??には考えてもらいたい。
> というより今までの流れの中で??「これだけは捨てられない」??ってポイントが、3点くらいはすぐに挙げられると思う。

そうですねぇ…
1.マルチスレッド周りの強化
2.後方参照の導入
3.ヘッダファイルの廃止
4.クラス、テンプレートの導入
ですね。なんか545さんの意見に便乗するようで悪いのですが、これが標準ということでよろしいですか?

600 :デフォルトの名無しさん:2009/08/15(土) 18:54:47
残したいC言語の特徴って何?

602 :303 ◆pFphp4Ej4w :2009/08/15(土) 19:54:07
>>600
重要度の高いものから順に
1.高い移植性
2.OSさえも(アセンブリ言語を一部使用しなければならないにしても)書けてしまうという高い柔軟性
3.高いパフォーマンス性能


664 :デフォルトの名無しさん:2009/09/05(土) 02:03:54
トランスレータでも構文解析の知識はいるだろうに。

666 :デフォルトの名無しさん:2009/09/06(日) 07:26:28
ソースはどこで見れんの?

667 :デフォルトの名無しさん:2009/09/06(日) 07:37:40
俺も以前C言語作ろうとしたんだけど
C言語て記号いろいろ使ってて、作るのめんどくなって途中で投げたんだ
printfと、if,elseまで作った時点でかなりソースが膨らんでてやる気がな・・・・
303がどこまで作れたのか興味深い

668 :303 ◆pFphp4Ej4w :2009/09/06(日) 09:00:21
>>664
まぁそうですが、最適化と実行ファイル生成とかがないだけ楽です。

>>666
http://github.com/385

で385氏がOCamlで書いたものが見れます…と思ったら無くなってますね…
とりあえずソースは手元にあるのでどこかうpろだ紹介してくださればそこにあげます。

>>667
C系の言語って他のプログラミング言語より圧倒的に演算子が多いですからね…

765 :303 ◆pFphp4Ej4w :2009/12/09(水) 11:32:34
すみません、
typedef struct Hoge{
/* ... */
union piyo{
int foo;
char bar;
}u;
}Hoge;

Hoge hogege;
hogege.u.foo = 3;

って感じで共用体をを使う人ってどれくらいいます?

766 :デフォルトの名無しさん:2009/12/09(水) 11:35:53
>>765
unionは普通そういう使い方はしない。
構造体内でバイト列の読み替えをするのに定義することが多い。

union piyo {
int foo;
char bar[4];
short poo[2];
};

といった感じ。

767 :303 ◆pFphp4Ej4w :2009/12/09(水) 11:44:40
>>766
確かにそういう使い方もありますわな。(完璧に処理系依存で、ほめられた使い方じゃないですが)

…で今回聞きたいのはそういうことではなくて、「構造体の中で共用体を宣言してしまう」人がいるか聞いたのですが…


http://hibari.2ch.net/test/read.cgi/tech/1185010023/l50人気ブログランキングへ

学ばないブログ
忍者AdMax
記事検索
最新コメント
QRコード
QRコード
  • ライブドアブログ