From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5071 invoked by alias); 9 Oct 2017 13:33:34 -0000 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 Received: (qmail 5031 invoked by uid 89); 9 Oct 2017 13:33:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=H*M:1046, (unknown) X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Oct 2017 13:33:32 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id v99DXL4V003603 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 9 Oct 2017 09:33:26 -0400 Received: from [10.0.0.11] (cable-192.222.251.162.electronicbox.net [192.222.251.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 8FAFF1E055; Mon, 9 Oct 2017 09:33:21 -0400 (EDT) Subject: Re: [PATCH v5 3/6] sim: or1k: add or1k target to sim To: Stafford Horne Cc: GDB patches , Openrisc , Mike Frysinger References: <20171005134912.26799-1-shorne@gmail.com> <20171005134912.26799-4-shorne@gmail.com> <2a5f900c-99e7-cb4b-9211-b9dab8414de5@polymtl.ca> <20171009130305.GC2958@lianli.shorne-pla.net> From: Simon Marchi Message-ID: <7089df6c-1046-1fd9-150d-1492d4734ac6@polymtl.ca> Date: Mon, 09 Oct 2017 13:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171009130305.GC2958@lianli.shorne-pla.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 9 Oct 2017 13:33:22 +0000 X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00197.txt.bz2 On 2017-10-09 09:03 AM, Stafford Horne wrote: >> That code looks strange to me. Enabling byte reordering (SR[LEE]) makes it so that each >> group of 4 bytes appears swapped in memory? Is this something a program can turn on/off >> at any time? There isn't much detail about that in the spec it seems. > > I have added some more comments to this in the next patch series. I am not > to sure as to the 'why' for this functionality. But I assume its probably > to interact with hardware like graphics cards which only support > little-endian addressing. The SR[LEE] would only be available to change in > supervisor mode, so not just any program could change it. > > The above code only handles the address translation (note for half-word > access openrisc requires the address to be half-word aligned). Ok, thanks for the explanation. > FYI, also the testsuite patch aas a few long lines like: > > /* The sign extension produces unexpected results here. */ > SHOULD_BE_LESS_THAN_UNSIGNED_I 0xFFFFFFFF - 1, 0xFFFF /* 0xFFFF gets sign-extended to 0xFFFFFFFF. */ > SHOULD_BE_LESS_THAN_UNSIGNED_I 0xFFFF7FFF, 0x8000 /* 0x8000 gets sign-extended to 0xFFFF8000. */ > > I guess it should be like this? I don't mind the inline comments, but I > guess convention is convention? > > /* 0xFFFF gets sign-extended to 0xFFFFFFFF. */ > SHOULD_BE_LESS_THAN_UNSIGNED_I 0xFFFFFFFF - 1, 0xFFFF > /* 0x8000 gets sign-extended to 0xFFFF8000. */ > SHOULD_BE_LESS_THAN_UNSIGNED_I 0xFFFF7FFF, 0x8000 Personally I prefer with the comment above. Simon