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 AAD37383B82C for ; Wed, 7 Jul 2021 18:45:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AAD37383B82C 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 fwd13.aul.t-online.de (fwd13.aul.t-online.de [172.20.27.62]) by mailout08.t-online.de (Postfix) with SMTP id 7454588434 for ; Wed, 7 Jul 2021 20:43:36 +0200 (CEST) Received: from [192.168.178.26] (EPXLckZfoh7RlO2g765LjYjrIT2G72gkF-JNnIrhs68EdW2TXeyJdhfu122E0GaQGS@[93.238.120.206]) by fwd13.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1m1CWG-0qbZ5c0; Wed, 7 Jul 2021 20:43:36 +0200 Subject: Re: Help porting newlib to a new CPU architecture (sorta) To: newlib@sourceware.org References: <02319db3-b410-18e8-ac8a-049c54e753b5@gmail.com> <87d0cba4-b71a-a79b-cff6-891c384c20d5@SystematicSw.ab.ca> <2bb2d181-36e4-1cc6-bdff-9eb0aea895ec@gmail.com> From: =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= Message-ID: <661253a7-00b8-02ac-4956-051f7be70231@t-online.de> Date: Wed, 7 Jul 2021 20:43:36 +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: <2bb2d181-36e4-1cc6-bdff-9eb0aea895ec@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: EPXLckZfoh7RlO2g765LjYjrIT2G72gkF-JNnIrhs68EdW2TXeyJdhfu122E0GaQGS X-TOI-EXPURGATEID: 150726::1625683416-00014A6A-85FB92A0/0/0 CLEAN NORMAL X-TOI-MSGID: 2431f1b0-46ad-4293-8cfa-e8fcefc63894 X-Spam-Status: No, score=-1.2 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: Wed, 07 Jul 2021 18:45:30 -0000 Am 06.07.2021 um 22:46 schrieb Orlando Arias: > Consider the AVR architecture, where program and data spaces have > distinct address spaces. We have a pointer to a string literal that > resides in program memory. You're already mixing stuff up again. The memory C string literals are in is, by definition, _not_ program memory. It's read-only data memory. That distinction is crucial. Small-ish embedded CPUs do not usually implement the strict Harvard architecture principle, precisely because that does not support constant data. A strict Harvard would have all data, including the const-qualified parts, in RAM, and initialize it all by running a very boring piece of program that just writes it all using immediate operands. const data would thus consume normal RAM, without any write-protection by the hardware at all. Micro controller designers have pulled different kinds of tricks to get around the need to have constants directly in ROM, ranging from the simple loop-hole instruction that does read from program memory anyway (like the 8051's MOVC), to various kinds of mirroring schemes that just map ROM into data space, essentially breaking the Harvard architecture rather fundamentally. But that's ultimately a problem for the implementer of the C compiler and run-time library to address, if they decide to try doing that on such small architectures. > The problem with this code is that we are treating a as a pointer in > data memory. Declaring a to be PROGMEM does not help. We actually need > to rewrite the code to force the compiler to use the proper instruction: That's what you get for throwing Standard C compatibility out the window by declaring that string constant using a compiler extension like PROGMEM. Generally the compiler would be required by the Standard to implement "generic pointers" that can reach _all_ kinds of data defined without use of non-standard means. If it doesn't do that, it is by definition not a C compiler. Which can be fine, e.g. if the architecture just cannot have a correct C implementation otherwise, or only a horribly inefficient one. But porting a generic standard C library like newlib or glibc onto a platform that needs non-standard compiler extensions just to emulate strcmp() may quickly turn into a lost cause. > Now, I believe that doing something like (char*)fn_ptr > in C is either undefined behavior It quite explicitly is.