From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) by sourceware.org (Postfix) with ESMTPS id D40313894436 for ; Tue, 6 Jul 2021 20:45:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D40313894436 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qk1-x735.google.com with SMTP id t19so6930154qkg.7 for ; Tue, 06 Jul 2021 13:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to; bh=/DVDeGkR7WUvYhhXe24Nzx6vNHpYu7iBU3zCbFVw8T8=; b=cB/xcW83IQzesY/KGFtqLotRJ5avYwJbz3ZlX0Q/CqV4LIKNRINnUizEHNX5/2aL4O K5A6PobVj4I7TL+2xaKxjToL7pE6/RMzENuVVCPrysF0r+7ER6eJH/nPktXWl+q7EgHB NF3cO9P0hol6dpIediubx00lGQt892gh2CYbCcGYfb3tIqyb+O24Wa43Ii/2zj0zdq60 QFx+uLXb4+YhWSlBznw6pFhlGbOEDf4CVU5kWe+kGpBuxpW2jr4e0I06vYCzC9PovBSu 5VeWJljka6CO5zOyrV45QEdvRvazHWPSBzJwhARiSKqyXhitV5Xf48EnXH5l/5EkfwBw iF8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to; bh=/DVDeGkR7WUvYhhXe24Nzx6vNHpYu7iBU3zCbFVw8T8=; b=KnSl6EhFb6TjQmu9SxfaWGUS2tNMnBUsojsDkfCOm7PKEYoHR+K5BOHcgPe5GoG5WQ lH5towltluXQsLV+o2JCaNmXz64CE8zOOQoI2zktxLPYJam71d0sSVeylzOjpKvTtzCE LYbBnnZjggegUS8M+RtdAggH84SGtTnQ8O0LhwXy0EYp1hEhQqrv/7yDoJVjwu7MEmB1 yT2Gk5iPDkS839D6zoTAurZglDGLK/Ib4V1/KzDMZbQ2ipKXlovdqrs1Q+s7LJ5IN27q qmlMt2BF/Wm6yW80gYTUs7lWskWZsC9TVcGn+7UTY2q4/eFJV60cU1TLFqi0PGwPX8C9 f17g== X-Gm-Message-State: AOAM532HPPqQySnjM6UPNOw6CdqtKnytviWwZa9fVrx54buLrFgoXjOE Gd12on8uBzohgXBYjf4AcGC2qA0XsRXvOQ== X-Google-Smtp-Source: ABdhPJwKr41zei6o6cnONd7wR/XAqg87zOxJmaU8M2xSQ08TL5SeDpluHCm7L+fj6rEg9f8Uvv2uXw== X-Received: by 2002:a37:9a8a:: with SMTP id c132mr8712070qke.366.1625604311299; Tue, 06 Jul 2021 13:45:11 -0700 (PDT) Received: from [0.0.0.0] (097-102-108-016.res.spectrum.com. [97.102.108.16]) by smtp.googlemail.com with ESMTPSA id s6sm7495522qkc.125.2021.07.06.13.45.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 13:45:10 -0700 (PDT) To: =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= , newlib@sourceware.org References: <02319db3-b410-18e8-ac8a-049c54e753b5@gmail.com> <87d0cba4-b71a-a79b-cff6-891c384c20d5@SystematicSw.ab.ca> From: Orlando Arias Subject: Re: Help porting newlib to a new CPU architecture (sorta) Message-ID: <2bb2d181-36e4-1cc6-bdff-9eb0aea895ec@gmail.com> Date: Tue, 6 Jul 2021 16:46:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xUl71LWFMunMT9fspd5S6OBKdwQGZxQN0" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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:45:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xUl71LWFMunMT9fspd5S6OBKdwQGZxQN0 Content-Type: multipart/mixed; boundary="6DLySCoFlOLbvHvHfHswENne68fYO5ux9"; protected-headers="v1" From: Orlando Arias To: =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= , newlib@sourceware.org Message-ID: <2bb2d181-36e4-1cc6-bdff-9eb0aea895ec@gmail.com> Subject: Re: Help porting newlib to a new CPU architecture (sorta) References: <02319db3-b410-18e8-ac8a-049c54e753b5@gmail.com> <87d0cba4-b71a-a79b-cff6-891c384c20d5@SystematicSw.ab.ca> In-Reply-To: --6DLySCoFlOLbvHvHfHswENne68fYO5ux9 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Greetings, On 7/6/21 4:01 PM, Hans-Bernhard Br=C3=B6ker wrote: > Am 06.07.2021 um 21:04 schrieb Orlando Arias: >=20 >> Right, went back and looked at the standard. There is no description o= f >> 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 standa= rd >> C has no way of signaling this.=20 >=20 > You're mixing thing up there.=C2=A0 Standard C has a perfectly fine > distinction between program space and data space, including pointers > thereto.=C2=A0 Function pointers and data pointers _are_ distinct. >=20 > What Standard C does lack is a standardized distinction between pointer= s > into ROM data and RAM data.=C2=A0 const-qualified pointers may seem lik= e they > offer that, but ultimately they don't. Possibly I am explaining myself incorrectly here, and likely I am mixing terminology, yes. There is also a good likelyhood I am conflating things as well. If that is the case, my apologies and please feel free to correct my understanding/terminology. What I mean to say is the following [through an example]. 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. We wish to compare it to a string that resides in data memory. We could use a [naive] comparison method, such as strcpy(). const char* str PROGMEM =3D "hello"; const char* a =3D str; const char* b =3D data_memory_location; while(*a !=3D '\0' && *a =3D=3D *b) { a++; b++; } return *a - *b; 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: char t; while((t =3D pgm_read_byte(a)) !=3D '\0' && t =3D=3D *b) a++; b++; } return t - *b; We use the pgm_read_byte() macro to issue the LPM instruction, instead of a regular load instruction. In fact, avr-libc provides a collection of functions [which can be identified by their suffix _P] for the particular event where data resides in program memory. For example, we have strcmp_P(), where the second argument refers to a pointer to data in the program memory address space. >=20 >> This is what I meant by the von Neumann requirement: all pointers >> dereference to the same address space.=20 >=20 > That's stated broadly enough to be wrong.=C2=A0 The C virtual machine i= s, in > fact, a Harvard architecture.=C2=A0 It assumes that const and non-const= data > live in the same address space, but that doesn't make it von-Neumann. Right, so herein lies a problem. A Harvard machine implies that program and data are in different address spaces. Unless my understanding is wrong, this means that there is one address bus for data, and one address bus for instructions. Dereferencing a function pointer and dereferencing a data pointer would result in dereferencing to different address spaces. Now, I believe that doing something like (char*)fn_ptr in C is either undefined behavior or implementation-defined behavior. However, the implementations I have seen would treat this pointer as something in data memory, rather than something in program memory. Actually modifying what fn_ptr points to would require the use of an extension to the language [which would be implied if the behavior was indeed UB or implementation defined]. Please correct me on this one. Cheers, Orlando. --6DLySCoFlOLbvHvHfHswENne68fYO5ux9-- --xUl71LWFMunMT9fspd5S6OBKdwQGZxQN0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iF0EAREKAB0WIQQNWDJzd34+k5noE3NTFb9QFn4uoQUCYOTBKQAKCRBTFb9QFn4u ob7bAJsGnnt0SZuY1h+iDvyqyqGyoOjUbACfTUqwmslG0vODYlmEivmSPw0fy08= =YjGY -----END PGP SIGNATURE----- --xUl71LWFMunMT9fspd5S6OBKdwQGZxQN0--