From mint-bounce@lists.fishpool.fi Tue Feb 5 16:01:44 2008 Message-ID: <47A8BBC4.4000405@freesbee.fr> Date: Tue, 05 Feb 2008 20:40:52 +0100 From: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mint Subject: Re: [MiNT] Alignment 2 References: <4798E197.6050500@freesbee.fr> <479E54DF.5050804@freesbee.fr> In-Reply-To: Content-Type: multipart/mixed; boundary="------------020702030904040500030605" X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: vincent.riviere@freesbee.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: This is a multi-part message in MIME format. --------------020702030904040500030605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Frank Naumann wrote: > The kernel manage big memory chunks, e.g. the=20 > smallest block you get from kernel by Mxalloc() is the system page size= =20 > (8 kb [except 68000 CPU where it is 512 byte]). >=20 > I don't looked at the code but I would assume that the Pexec loader loa= d=20 > the code aligned into the memory block (the memory block is page aligne= d=20 > for sure). He he... The BASEPAGE is aligned on a memory block. The text segment is=20 256 bytes further... so it is only aligned on a 256 byte boundary !=20 Anyway, it is far enough :-) I made some tests with the attached program, in order to determine the=20 worst (lower) alignment where the OS loads the .text segment. Here are the results: Real Atari STe with TOS 1.62: 2 ARAnyM with TOS 4.04 (without MiNT): 4 ARAnyM with FreeMiNT: 256 So the conclusion is: On the ST: alignment to more than 2 will not be respected by the OS.=20 Furthermore, it would be useless for the 68000 CPU. So, definitely, the=20 good alignment for the ST target is 2 bytes (not a real surprise :-) ) On the Falcon: alignment of 4 will be respected by the OS. Such=20 alignment is useless for the standard hardware, but it is faster when=20 using an accelerator card with FastRAM. So we should have 2 configurations for our development tools for optimal=20 size and performance : "Optimized for ST": -m68000, no FPU, alignment on 2 "Optimized for Falcon": -m68020-60, with FPU, alignment on 4 That would be good. --=20 Vincent Rivi=E8re --------------020702030904040500030605 Content-Type: text/plain; name="pralign.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pralign.c" /* pralign.c * By Vincent Riviere, 2008 * * Compile with: * gcc -O2 -s -Wl,--mno-altram,--mno-altalloc -s pralign.c -o pralign.tos * * This program displays the alignment of the current .text segment. * Then it Malloc's a buffer of different sizes, and it runs itself again. * * The purpose is to determine the worst possible .text alignment on a given system. */ #include #include #include int get_alignment(void* p) { unsigned long adr = (unsigned long)p; int alignment = 1; if (p == NULL) return 32; while (!(adr & 1)) { alignment *= 2; adr >>= 1; } return alignment; } int main(int argc, char* argv[]) { unsigned long fillsize; void* filler; printf("text = 0x%08lx, align = %d\n", _base->p_tbase, get_alignment(_base->p_tbase)); if (argc > 1) return 0; for (fillsize = 1; fillsize <= 256*1024; fillsize += 2) { filler = (void*)Malloc(fillsize + 2); if (filler == NULL) { puts("Out of memory"); return 1; } Pexec(0, "PRALIGN.TOS", "norecurse", NULL); Mfree(filler); } return 0; } --------------020702030904040500030605--