From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout08.t-online.de (mailout08.t-online.de [194.25.134.20]) by sourceware.org (Postfix) with ESMTPS id B4D8238930EF for ; Tue, 6 Jul 2021 20:01:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B4D8238930EF Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=t-online.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=t-online.de Received: from fwd35.aul.t-online.de (fwd35.aul.t-online.de [172.20.27.145]) by mailout08.t-online.de (Postfix) with SMTP id 63F7B90A3D; Tue, 6 Jul 2021 22:01:07 +0200 (CEST) Received: from [192.168.178.26] (TWxz40ZlYh1N1Dmyqzk2Ofj7aikqtCFGOrBraJC8Xv0-kNjAZSKLl1Obj2CVxrwQER@[93.238.120.206]) by fwd35.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1m0rFi-14xgP20; Tue, 6 Jul 2021 22:01:06 +0200 Subject: Re: Help porting newlib to a new CPU architecture (sorta) To: Orlando Arias , newlib@sourceware.org References: <02319db3-b410-18e8-ac8a-049c54e753b5@gmail.com> <87d0cba4-b71a-a79b-cff6-891c384c20d5@SystematicSw.ab.ca> From: =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= Message-ID: Date: Tue, 6 Jul 2021 22:01:06 +0200 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: TWxz40ZlYh1N1Dmyqzk2Ofj7aikqtCFGOrBraJC8Xv0-kNjAZSKLl1Obj2CVxrwQER X-TOI-EXPURGATEID: 150726::1625601666-0000C8B5-4DF85BC7/0/0 CLEAN NORMAL X-TOI-MSGID: f4b6e087-ed7d-4511-9d7e-872ca6b0817c X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, FREEMAIL_FROM, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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 20:01:12 -0000 Am 06.07.2021 um 21:04 schrieb Orlando Arias: > Right, went back and looked at the standard. There is no description of > what the abstract machine for the execution environment should be. I > guess my confusion came from the second paragraph in [1]. Harvard > architectures still have the thing that you have to define whether a > pointer refers to something in program space or data space, and standard > C has no way of signaling this. You're mixing thing up there. Standard C has a perfectly fine distinction between program space and data space, including pointers thereto. Function pointers and data pointers _are_ distinct. What Standard C does lack is a standardized distinction between pointers into ROM data and RAM data. const-qualified pointers may seem like they offer that, but ultimately they don't. > This is what I meant by the von Neumann requirement: all pointers > dereference to the same address space. That's stated broadly enough to be wrong. The C virtual machine is, in fact, a Harvard architecture. It assumes that const and non-const data live in the same address space, but that doesn't make it von-Neumann.