なんか出てきたのでアップ。
♪ DARWIN 4078 - start 〜 bgm1 PMDソース
頼まれて作った耳コピーもの。割とそのままかな。元がOPLで太い音なのに対し、
こちらはOPNAなので若干細いか。音源クロックの都合で少し音程が高いです。
MMLをつけたので、誰かBGM2とBGM3とGAME OVERとNAME ENTRYを作ってください。
デコ祭が始まるよ。
♪ GALAXY FORCE II - Beyond the galaxy PMDソース
FM TOWNS版のハウスアレンジを、更にPMDPPZにコピーアレンジしたもの。
SEGA AGES 2500シリーズ Vol.30 ギャラクシーフォースII へのTOWNS版アレンジ
収録を祝うべく発売日あわせで用意していましたが、内蔵音源ともＤＡ音源とも
つかない中途半端な出来になったのと、あと、そもそもお祝いにならないような
気がして、お蔵入りに。
MMLをつけましたが見ない方がいいような気がします。
♪ AFTER BURNER II - AFTER BURNER (最初のサビまで)
まだAB2のサントラを持っていなかった頃、雑誌投稿や草の根BBSのコピー作品を
聴いたり、様々な情報を総合して、アーケードの音源を妄想したもの。しょーも
ない音源ですね！
http://www.jitu.org/~tko/cgi-bin/bakagaiku.rb?bakaid=20080120
やばい、まさにナウ、今から、「なんとなく」でmallocのせいにする日記を書く
所だった。全然面識のない方なのに何故バレたんだろう。（ヒント：単なる偶然）
先日コルーチンで敵ジェネレータを作ったが、その際、敵を生成する瞬間ハング
アップするのでスタックサイズを増やして対処した。
で、そのスタック領域を確保するときにmallocを使ってたわけで、つまりコルー
チンからコルーチンを生成するときmallocがコールされてたわけで、コールして
チーンなわけで、mallocがスタック喰いまくってたに違いないと。
（敵ジェネレータ生成直後：赤い部分がスタック領域）
（敵ジェネレータが敵を生成した直後）
そんでもってmallocの代わりに自前の配列プールを使うことにし、コールチーン
的には一応解決したものの、一応mallocの動きを調べてみても損は無い気がした
ので、newlibを落としてきて malloc でgrep。ひたすらgrep。
newlib/stdlib/malloc.c(191): _DEFUN (malloc, (nbytes),
_PTR
_DEFUN (malloc, (nbytes),
size_t nbytes) /* get a block */
{
return _malloc_r (_REENT, nbytes);
}
で、_malloc_r は
newlib/stdlib/mallocr.c(1002): #define mALLOc _malloc_r
で、 mALLOc は
newlib/libc/stdlib/mallocr.c(2319): Void_t* mALLOc(RARG size_t bytes)
Void_t* mALLOc(RARG size_t bytes)
{
...
remainder_size = long_sub_size_t(chunksize(top), nb);
if (chunksize(top) < nb || remainder_size < (long)MINSIZE)
{
...
malloc_extend_top(RCALL nb);
...
mALLOc だけでかなりスタック消費してそうな感じだけど一応先に進む。
で、malloc_extend_top は
newlib/libc/stdlib/mallocr.c(2132): static void malloc_extend_top(RARG INTERNAL_SIZE_T nb)
static void malloc_extend_top(RARG INTERNAL_SIZE_T nb)
{
char* brk; /* return value from sbrk */
...
brk = (char*)(MORECORE (sbrk_size));
...
で、MORECORE は
newlib/libc/stdlib/mallocr.c(304): #define MORECORE(size) _sbrk_r(reent_ptr, (size))
で、_sbrk_r は
newlib/libc/reent/sbrkr.c(52): _DEFUN (_sbrk_r, (ptr, incr),
void *
_DEFUN (_sbrk_r, (ptr, incr),
struct _reent *ptr _AND
ptrdiff_t incr)
{
char *ret;
void *_sbrk(ptrdiff_t);
...
で、_sbrk は
libgloss/arm/syscalls.c(591): _sbrk (int incr)
caddr_t
_sbrk (int incr)
{
extern char end asm ("end"); /* Defined by the linker. */
static char * heap_end;
char * prev_heap_end;
if (heap_end == NULL)
heap_end = & end;
prev_heap_end = heap_end;
if (heap_end + incr > stack_ptr)
...
と。ようやく終点に辿りついた。
こんなに入れ子してたらそりゃスタック食うよなぁと思いました。
ん、ちょっと気になるところが……
/* Register name faking - works in collusion with the linker. */
register char * stack_ptr asm ("sp");
へぇ、こうすれば C からスタックポインタ参照出来るんだ。おもしろ。
なんとかしなきゃな……。
以前、ネタで三重マッドボールを作ってみたら、結構大変だった。外側の砲台を
破壊したときは内側の連絡橋も同時に壊れなくちゃいけなくて（逆に、連絡橋を
先に壊しても外側の砲台が壊れる）、本体→連絡橋→砲台→砲台同士の連結橋と
いう順番で親子関係を持たせてみたらコードが滅茶苦茶になった記憶がある。け
ど、どう滅茶苦茶だったのかは忘れた。（オイオイ） 確か、外から順番に壊す
分には大丈夫なんだけど内側の本体を真っ先に破壊すると、子供が変なところを
参照してぐだぐだになったような。まぁどうでもよい話です。
Hello webmaster
I would like to share with you a link to your site
write me here preonrelt@mail.ru (2009/03/05 03:37:55)