From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) by sourceware.org (Postfix) with ESMTPS id D3626383D803 for ; Tue, 6 Jul 2021 18:08:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D3626383D803 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=systematicsw.ab.ca Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id 0cJNm8DvDFRDp0pUtmbd3J; Tue, 06 Jul 2021 18:08:39 +0000 Received: from [192.168.1.104] ([68.147.0.90]) by cmsmtp with ESMTP id 0pUsmsL0OB9dP0pUtmc74L; Tue, 06 Jul 2021 18:08:39 +0000 X-Authority-Analysis: v=2.4 cv=Ac10o1bG c=1 sm=1 tr=0 ts=60e49c27 a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=IkcTkHD0fZMA:10 a=uYT-Tk0qkVT609LjNaIA:9 a=QEXdDO2ut3YA:10 Reply-To: newlib@sourceware.org To: newlib@sourceware.org References: <02319db3-b410-18e8-ac8a-049c54e753b5@gmail.com> From: Brian Inglis Organization: Systematic Software Subject: Re: Help porting newlib to a new CPU architecture (sorta) Message-ID: <87d0cba4-b71a-a79b-cff6-891c384c20d5@SystematicSw.ab.ca> Date: Tue, 6 Jul 2021 12:08:38 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <02319db3-b410-18e8-ac8a-049c54e753b5@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfN7PCDoVOF6ruwXAor9tCy7P2v+XdjBoiXJRftqhKKLux0KnB0Z2gya8oV5FSOW2Q+Mwe/I0+ycHYHQOQGOj+h0kemVWl03hsUPLO8YXHkz1NNFzYkWa VD+RAi4apgYQTPo9Pz208RJ9V2Jl9a9kolr2RNUZ0BsRMRCHagE2tpIUxRcUhv5tMZ6wm2I1BuZtqXz9skA707mcjQt67hbQz0g= X-Spam-Status: No, score=-1161.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 18:08:41 -0000 On 2021-07-06 08:35, Orlando Arias wrote: > Keep in mind that C assumes you are working on a von Neumann > architecture. This means that the language expects both program and data > to be in the same address space. If your CPU [which I can not really > check since I do not work on Logisim, I use Verilog/SystemVerilog/VHDL > myself] uses a Harvard or modified Harvard architecture, you need to > figure out a way for your C runtime to emulate a von Neumann machine. C has no assumptions or requirements for outdated von Neumann architectures, but it also may not assume it is not running on such architectures. Early C and Unix took advantage of the Harvard architecture of larger PDP-11s which supported split I/D space with mapping registers to support double the program size (64KB each 16b I and D) as well as splitting kernel/supervisor/runtime/user spaces [and similar features on other systems], and shared text (the original meaning of the 't' "sticky text" perm on executables), which is why there is wording in the standards about unmodifiable constant values. One of the big issues with systems around the time C was developed was the unreliability resulting from systems, runtimes, and programs using self-modifying code "tricks", and programs ability to change constant data values used in programs (PI did not always stay π). That was one of the benefits touted for higher level system implementation languages such as Bliss, C, PL/S. In the face of failures frequently caused by arbitrary code and data modifications, branches and jumps, worries about trivial issues such as delimited strings, unsized APIs, dynamic memory management were decades in the future! Various implementations, ABIs, and systems require modifiable code and constant data, but it is *NOT* a C language assumption or requirement; in fact I would consider it to be a C anti-pattern, that has long limited the abilities of compilers and optimizers to do better jobs. Copying sections tends to be due to limitations of CPUs, systems, runtimes, or compilers to DTRT to make programs more reliable. ;^> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]