W dniu 2023-02-15 o 19:50, heby pisze:

> I nagle chcesz odczytywać wewnatrzny status CPU, co do którego nie ma
> nawet pewności, że istnieje na jakiejś architekturze sprzętowej, ani jak
> działa w konkretnym przypadku. To proszenie się o katastrofę. Od tej
> pory C musiał by być *tylko* na procesory z flagą C i to w dodatku
> działającą w jakiś specyficzny sposób. A jak jej nie ma wcale?

Akurat brat przyszedł do mnie z pytaniem, jak coś zrobić w C (o tym
dalej bo ja nie znam odpowiedzi ale powiedziałem mu, że zapytam
mądrzejszych ode mnie) więc wspomniałem mu o tym co tu napisałem o bicie
przeniesienia, czy parzystości.

On ma całkiem odmienne zdanie od Twojego.
Nie widzi żadnego problemu, aby w C dla zmiennych całkowitych było na
przykład pojęcie bitu parzystości. Jak procesor go ma to kompilator
korzysta bezpośrednio, a jak nie ma to wtedy wylicza tak jak ja w tej
crc16().
Gdzie tu proszenie się o katastrofę?
A....
Nie wspomniałem mu o różnych reprezentacjach zmiennych o których pisałeś
z czego on (tak jak i ja) całkowicie nie zdaje sobie sprawy. Ale
faktycznie są stosowane jakieś inne reprezentacje?

A teraz pytanie brata na które nie znamy odpowiedzi.

Ogólnie to jest pierwsze podejście do procesorów ARM (nie wiem z którym
w tej chwili walczy (Silabs EFM32PG22..., EFM32PG23..., a może EFM32TG11..).
Zanim użyje procesor po raz pierwszy musi opanować podstawowe działania
no i jest właśnie na tym etapie.

On by potrzebował sizeof(funkcja).

Ale jak próbuje to zrobić to dostaje 1.
Zasugerowałem, że może jak wstawi etykietę (przypomnieliśmy sobie, że
chyba w C coś takiego jest) na nawiasie zamykającym funkcję to uda się
policzyć różnicę między jej adresem a adresem początku funkcji.
Właśnie mi krzyknął (jego pokój jest piętro niżej), że z zewnątrz
funkcji nie ma dostępu do tej etykiety.

Napiszę do czego mu to potrzebne bo czasem może rozwiązanie głównego
problemu robi się inaczej niż on kombinuje.

Wczoraj wieczorem wspólnie tłumaczyliśmy dwa akapity datasheet, czy
manuala (nie wiem - on mi po prostu podświetlił akapit na ekranie i
chodziło o to jak to rozumiemy).

Tam było, że jak się coś robi z programowaniem flasha z wnętrza programu
to ogólnie nie ma gwarancji, że wszystko się uda. I to zdanie było
ogólne - czyli nawet jak ruszasz inną stronę niż jesteś to może coś nie
zadziałać. Nie napisali co dokładnie, ale skoro może coś się nie udać to
my tego nie chcemy. Napisali, żeby przekopiować odpowiednią funkcję do
RAMu, wywołać ją i z niej uruchomić proces kasowania, czy programowania
flasha.

Już opanował wywoływanie funkcji po jej skopiowaniu do RAMu.
Z adresem początku sobie radzi, choć mówi, że wskaźnik na funkcję jest
zawsze większy o 1 od prawdziwego adresu i ustalając fragment do
kopiowania on musi tę jedynkę odejmować.
Wszystko już działa, tylko, że na razie rozmiar funkcji bierze z sufitu
na zapas.

No i jedyne co brakuje do odhaczenia kolejnej funkcjonalności to
ustalenie w jednej funkcji jaki jest sizeof drugiej funkcji.

Może wiesz (lub ktoś inny) jak to się robi.
P.G.