From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10389 invoked by alias); 16 Nov 2011 21:45:31 -0000 Received: (qmail 10378 invoked by uid 22791); 16 Nov 2011 21:45:31 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Nov 2011 21:45:17 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 71B531B4023; Wed, 16 Nov 2011 21:45:16 +0000 (UTC) From: Mike Frysinger To: gdb-patches@sourceware.org Subject: Re: [sim] new port: Renesas RL78 Date: Wed, 16 Nov 2011 21:45:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.1.0; KDE/4.6.5; x86_64; ; ) Cc: DJ Delorie References: <201111160606.pAG66U4p017015@greed.delorie.com> <201111161936.pAGJaKfW006960@greed.delorie.com> <201111161447.29112.vapier@gentoo.org> In-Reply-To: <201111161447.29112.vapier@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4395481.zFhSmRvPdG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201111161645.18021.vapier@gentoo.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00456.txt.bz2 --nextPart4395481.zFhSmRvPdG Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-length: 1226 On Wednesday 16 November 2011 14:47:28 Mike Frysinger wrote: > On Wednesday 16 November 2011 14:36:20 DJ Delorie wrote: > > > > +int > > > > +main (int argc, char **argv) > > > > +{ > > > > ... > > > > + setbuf(stdout, NULL); > > >=20 > > > doesn't this hurt performance ? especially when tracing ? > >=20 > > Very important when emulating the target serial port, though. I > > suppose I could rework that logic, but so far I've mostly been worried > > about "runs correctly" and not "runs fast". >=20 > for output, i have my uart simulator explicitly flush whenever it has data > to right. that way general things writing to stdout don't take a penalty, > but the serial which wants bytes sent immediately still work. ugh, s/right/write/ in case it's interesting, i'm referring to the file sim/bfin/dv-bfin_uart.c= . in=20 there is a bfin_uart_write_buffer() helper which is called two different wa= ys:=20 when a buffer is transferred to the device via DMA (so from=20 bfin_uart_dma_write_buffer() which is a callback from common device framewo= rk),=20 or when someone writes the memory-mapped transmit register (so from=20 bfin_uart_io_write_buffer() which is a callback from common memory framewor= k). HTH -mike --nextPart4395481.zFhSmRvPdG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJOxC7tAAoJEEFjO5/oN/WBLggP+wXdmE74LfNQFmEvj6t1hUyq pW0wAkb4uFRw94eg6L6hUneklccLMa+72bPlcVY/AB/fx1VTBxwgydFPPBcq7rkG jZiBRZ2FQ6JaiRNK4VJX9XgnFISyTrdIU6v1mdAPGplNTvidh9sSAlc9nNWHW8i3 BT8jGuMQgX/MTQuxGo2qNyPG4Yzie3gkYaDVqJnKrMpcSllBIU5gKvC3P9ge9Y7c 7e6+FT3KjOrZlua/7ABiwUZSf2tyfar7goV4UjAhLgkB7+UxXd6OryYI4GS2jQYn 6cRCP7talw5uhsyrVnQeWGyrxZ0M1bg096QFQZqvE+sgD6vJ5Pnzb0YdndgmqPFP DQnhHs7UIV0pzEe9uECP5Hc+BULJHzgj4Y1jft76lt3wAMnu6FXpkbqNDh4R0A1M uS2qFeHgaUox8/ROvVtdp3MUA1O6S9o0FOdQuou9DDcvgNsNDC3dKHqUaFwO72Y9 UjsxWZ5eYsokG7NB72TJiqYuFEy1AnEA9+y7p0wU7zVo07n+tc/YiK9C/stOc1vx nTSCaqBzH6FIMZLPGa9M2tltnDYky1jZo1koTyZMZIt50xR0wuG5Dz8itSTFJ47i y01Gzr53XGSnEuQjoT7i9ZI1DnfbqQlR7tODYERvJIDNhwzXlXJ5FJdwURImd1Ac qdKLjxmpnYmmj/5hLwIQ =R8zn -----END PGP SIGNATURE----- --nextPart4395481.zFhSmRvPdG--