機械語なら俺に質問しろ！

訂正

LSI-C80 → LSI C-80
LSI-C86 → LSI C-86

先ず第一に、80と86ではコードジェネレータが違うこと。
→80版は86版ほどタイトなコードは生成しない。
第二に、初回のジャンプを省略しようかと言うレベルの話をしていること。
→8086のコードは参考にしかならない。
全く的外れと言わざるをえない。

>>953
>先ず第一に、80と86ではコードジェネレータが違うこと。
>→80版は86版ほどタイトなコードは生成しない。

じゃあどんなコード吐くの? 参考に晒してくれたっていい罠。

>第二に、初回のジャンプを省略しようかと言うレベルの話をしていること。

少なくとも>>930-931はそんな話してない訳だが。

>→8086のコードは参考にしかならない。

参考になるならいいじゃん。アホか?

>>953
>第二に、初回のジャンプを省略しようかと言うレベルの話をしていること。

そこまで気にすんなら関数呼び出しのコストも削れよｗ

>>954 名前：デフォルトの名無しさん[sage] 投稿日：2012/12/19(水) 12:27:27.27
そう真っ赤になるなって。自分の投稿時間でも眺めて和めよ。

和んだ

>>930
>8085用のLSIC-80で、３行分溜めてからまとめるコードを以下のように書いていた。
>　　strcpy(dst,１行目);
>　　strcat(dst,２行目);
>　　strcat(dst,３行目);

>strcpyした末尾アドレスをそのまま返せばstrcpyと同程度の性能になるのに許せん！

実際その部分が全体のパフォーマンスにどの程度影響及ぼしてるわけ？
多少効率が悪かろうとも、間に合ってるなら以降の作業は徒労ということになるが。

sprintfで実数変換使うと間に合わない、整数変換でも幾つもやると同様、ぐらい。
4800BPSを4CH同時に入出力してて、あるCHがこの例です。1CHだけならイイが、
4CHみんな整数変換とかstrcatを使うと危ないので軽くできればしておきたいです。

間に合わない＝受信ringで周回遅れが発生して行の再構成が失敗します。
clockは3.072MHzで、これを8253で分周して8251用と10mS割込用のclock作ってます。
まあ、暇だから最適化で遊んでるってのもありますけど。

sprintf() 既に使ってるなら、

sprintf(dst, "%s%s%s", １行目, ２行目, ３行目);

とか書けば保守性は向上するな。
sprintf()の実装や連結する文字列のバイト数によっては負荷ともなりうるが。

>>959
>sprintfで実数変換使うと間に合わない、整数変換でも幾つもやると同様、ぐらい。

重い箇所分かってんなら最適化で一番効果が期待できるのはそこだが？

>>930
>8085用のLSIC-80で、３行分溜めてからまとめるコードを以下のように書いていた。
>　　strcpy(dst,１行目);
>　　strcat(dst,２行目);
>　　strcat(dst,３行目);

最初からひとつのバッファに3行分溜めればまとめる必要もねんじゃね？

Cで速度最優先なら、str系ではなく、自分で長さを保持して全てmemcpy。
それでもダメってところで、ようやくアセンブラ。

>sprintfで実数変換使うと間に合わない、

LSI C-80って基本的な仕様が古いみたいだし、実数はfloatでも一旦doubleに昇格してから
演算するとかですげえ遅いんじゃないの？C89以前では普通だったけど。

実数が本当に必要かも検討するべき。

LSI Cは実数遅いよ。余りチューンしてないってpnoriさんが言ってた。
まして80じゃぁしょうがない。多分自力で固定小数点数ライブラリを作るのが一番。

>>963
>Cで速度最優先なら、str系ではなく、自分で長さを保持して全てmemcpy。

8085での実装なら、memcpy()よりstrcpy()の方が速い。

訂正

8085での実装なら、memcpy()よりstrcpy()の方が速い。
↓
8085での実装で、場合分けによる処理の最適化をしない前提なら、memcpy()よりstrcpy()の方が速い。

LSI C-80での実装がどうなってるかは知らん。

>>959
暇ならLSI C-80に>>951のソース喰わしたらどういうコード吐くかやってみて

%16　　　　; ここがwhile の行。
__2:
　　　　LDAX　　　　D
　　　　MOV　　　　M,A
　　　　ORA　　　　A
　　　　JZ　　　　__3
%17
　　　　INX　　　　H
%18
　　　　INX　　　　D
%19
　　　　JMP　　　　__2
__3:
%20
　　　　RET
JMPが２つあるのでサイズ最小ではないけど、素直なコードですね。
_asm_が混じるｃコードより可読性はグー！
memcpyよりstrcpyのほうが速いのは知って使ってます。

>>969
成る程、86版とは違うコードになるんだなあ。
1ループ中にジャンプ命令が2回あるからコピーする文字列が長いと86版に比べて効率は悪いが、
逆に、コピーする文字列が""で、結果1バイトしかコピーしない場合には効率は良いとも言えるな。

　　　　JZ　　　　__3
(略)
__3:
　　　　RET

のところは

　　　　RZ

になってればループを抜けなかった際のサイクル数が少なかったのに惜しい。

R<条件> と、C<条件> はLSIC-80に実装されてないんですよね。なので、
　　if( r_ptr ^ w_ptr )
　　　　func( );　　　は、lda r_ptr、lxi H,w_ptr、xra M、JZ 飛び越し、call func
が出ます。　これを lhld r_ptr、mov A,H、xra L、cnz func と、最適化しました。
（r_ptrとw_ptrは並んでいるので）　メインループ中にこれが４種類あるので、
メモリアクセス削減になってます。

２ちゃんもひと少なくなったな

8085用 romlibのｃコード読んでたら、strncat( ) は目的stringの末尾にnullをsetする
だけなのに、strncpy( ) は、目的stringがソースより長いとき 「残りを全て0で埋める」
ように書かれていました。　これは実害は無いにしろ、「余計なこと」 ですね。

>>970 ループ中に毎回NOPのジャンプが実行されるのが、素直なコードの悔しい所ですね
char*stpcpy2(char *s, const char *t) {
　　　goto do2;
do1: s++; t++;
do2: if (*s = *t) goto do1;
　　　return(s);
} これだと頭のジャンプ１回が静的動的に無駄なだけで、あとはASMのコードと同性能
_asm_で書くより可読性は良いから、ｃでの実装にはこれがベストかと。

>>973
それがstrncpy()の奇妙な仕様。なので、余計ではない。

え〜？？　ほんとだ。わざわざそのように断ってある。なんでこんなことに
なってるんだろう？　末尾nullだけでは困る事情がかつてあったのだろうか。

>>974 をfor( ; (*s=*t); s++,t++ ) ; と書くと、素直版と同じコードになっちゃうんですね。
forで、頭JMPで実行条件判定に飛び込むパターンも見たことあるのですが、何が
決め手になるのかよく判らないなあ。

strcat( d, s ) の中身：strcpy(d+strlen(d),s); return( d ); の展開が↓
　　push　　H
　　push　　D
　　pop　　　H
　　push　　H
　　push　　H
　　call　　　LAUTO4
　　call　　　strlen
　　mov　　　C,L
　　mov　　　B,H
　　call　　　LAUTO4
　　DAD　　B
　　POP　　D
　　call　　　strcpy
　　call　　　LAUTO2
　　pop　　　B
　　pop　　　B
　　ret　　コールが５回もあるの(*o*) あんまりだ！

ASMにしてみたのがこれ：　合ってるよね？
strcat_:　　; char　　*strcat(char *s, const char *t) {
　　push　 　H　　　　　　　　; 第１引数を保存
　　mov　　　A,M
　　inx　　　　H
　　ora　　　　A
　　jnz　　　　$-3　　　　　　　　; 末尾を探す
　　dcx　　　　H　　　　　　　　　; 末尾アドレスに戻す
　　call　　　　strcpy_ 　　　　　; その位置にcopy
　　pop　　　　H　　　　　　　　　; 第１引数を復元(HL=返却値)
　　ret

>>979
call して pop hl する代わりに、pop af して jmp してはどうだろう。

あ、なんだ、保存する必要さえなかったか。

>>979
速度優先なら、PUSH H〜POP HはBC に退避〜復帰させた方が早い。
但しstrcpy()の中で破壊されないこと前提になるから保守性は低下する。
strcpy()も展開した方がいいな、速度優先なら。

失業したおっさんらに質問です
OS創りたいのですが
何から始めれば良いでしょう

>>983
PCを拾ってくる

>>983
バイトでもいいから仕事に就く

>>983
まずOSを創ります → 終了

マジレスするが、まずは失業しておかないと、創る時間とれないよ

失業せずにOSを作れないようなら、シングルタスクのOSを作る頭脳しかない。

今日の大喜利会場はここですか？

>>980 動作変わっちゃいませんか？返却値は目的stringの頭ですけど、
strcpyする時は目的stringの末尾ですよね。

>>982 速度だけ優先ならそうですね。libであることを考慮すると速度・サイズ両面で
納得のゆく落とし所、ということで979にしました。　同サイズで速度ちょっと改善版：
strcat_:　　; char　　*strcat(char *s, const char *t) {
　　push　 　H　　　　　　　　; 第１引数を保存
　　xra　　　A
　　cmp　　　M
　　inx　　　　H
　　jnz　　　　$-2　　　　　　　　; 末尾を探す
　　dcx　　　　H　　　　　　　　　; 末尾アドレスに戻す
　　call　　　　strcpy_ 　　　　　; その位置にcopy
　　pop　　　　H　　　　　　　　　; 第１引数を復元(HL=返却値)
　　ret
徹底するなら速度版とサイズ版２種のlibを用意するのがイイですね。

発端は、「libは、コンパイラ開発メーカーの（自分より頭のイイ）人が書くのだから、
速度・サイズ両面で充分練られた物だろう」 と思いこんでいたのが違った、という話。
乗除算のルーチンなんかはきっちりコンパクトでしたけどね。
stringがこんだけルーズだと、printf系なんか読んだら憤死するかも(^o^)

うめますね(^o^)

うめ

うめ

１０年も続いたのね、このスレ。まだ8085の話したいから立てました（ｗ

http://toro.2ch.net/test/read.cgi/tech/1356735624/

うめ

JR $-2

うめ

うめ

76

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。