From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B3i16-0000Xb-TO for qemu-devel@nongnu.org; Wed, 17 Mar 2004 15:51:56 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B3hzi-0008NL-4w for qemu-devel@nongnu.org; Wed, 17 Mar 2004 15:51:01 -0500 Received: from [213.191.74.84] (helo=mx2.ngi.de) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B3hzM-0007vC-Bs for qemu-devel@nongnu.org; Wed, 17 Mar 2004 15:50:08 -0500 Date: Wed, 17 Mar 2004 19:07:00 +0100 From: Richard Zidlicky Message-ID: <20040317180700.GB2562@linux-m68k.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Subject: [Qemu-devel] [patch] m68k updates #2 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fabrice Bellard , Qemu ML Hi, this is experimantal and I am open to suggestions how to do it better. m68k does not have any rdtsc equivalent so I have to work around it like this - normal timer may have very low resolution (around 1/200 s). Afaics the better alternative would be to count instructions in generated code blocks and calculate clock value from this somehow. Richard diff -urN qemu-cvs/vl.c qemu-cvs-new/vl.c --- qemu-cvs/vl.c Mon Mar 15 00:43:15 2004 +++ qemu-cvs-new/vl.c Wed Mar 17 18:35:55 2004 @@ -346,6 +346,30 @@ return val; } +#elif defined(__mc68020__) + +/* crude hack to get some sort of rdtsc support */ + +#include +static int64_t cputicks=0; +static struct timeval lastcptcall={0,0}; + +/* assume 5 MHz Pentium, min 80 ticks between rdtsc calls */ + +int64_t cpu_get_real_ticks(void) +{ + struct timeval tp; + gettimeofday(&tp,(void*)0); + if (tp.tv_sec == lastcptcall.tv_sec && + tp.tv_usec == lastcptcall.tv_usec ){ + cputicks += 1; + } else { + cputicks=0; + lastcptcall=tp; + } + return ((int64_t)tp.tv_sec*1000000+tp.tv_usec)*5+cputicks; +} + #else #error unsupported CPU #endif