eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingDlaczego software to F35 jest pisany w C++ a nie w AdaRe: Dlaczego software to F35 jest pisany w C++ a nie w Ada
  • Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
    atman.pl!news.task.gda.pl!not-for-mail
    From: Baranosiu <r...@w...pl>
    Newsgroups: pl.comp.programming
    Subject: Re: Dlaczego software to F35 jest pisany w C++ a nie w Ada
    Date: Mon, 29 Oct 2012 11:01:15 +0000 (UTC)
    Organization: CI TASK http://www.task.gda.pl/
    Lines: 46
    Message-ID: <k6lnlo$9eu$1@news.task.gda.pl>
    References: <3...@g...com>
    <3...@g...com>
    <k3idkc$ne3$1@node2.news.atman.pl>
    <9...@g...com>
    <k3spfr$46s$1@node2.news.atman.pl>
    <8...@g...com>
    <e...@g...com>
    <1...@g...com>
    <k695i4$gg0$1@news.task.gda.pl>
    <8...@g...com>
    <k6boug$3gr$1@news.task.gda.pl>
    <2...@g...com>
    <k6gsh9$8qr$1@news.task.gda.pl>
    <b...@g...com>
    Reply-To: Baranosiu <r...@w...pl>
    NNTP-Posting-Host: user-46-112-51-197.play-internet.pl
    Mime-Version: 1.0
    Content-Type: text/plain; charset=iso-8859-2
    Content-Transfer-Encoding: 8bit
    X-Trace: news.task.gda.pl 1351508475 9694 46.112.51.197 (29 Oct 2012 11:01:15 GMT)
    X-Complaints-To: a...@n...task.gda.pl
    NNTP-Posting-Date: Mon, 29 Oct 2012 11:01:15 +0000 (UTC)
    User-Agent: slrn/pre1.0.0-18 (Linux)
    Xref: news-archive.icm.edu.pl pl.comp.programming:200445
    [ ukryj nagłówki ]

    Dnia 29.10.2012 Maciej Sobczak <s...@g...com> napisał/a:
    >> Po prostu
    >> był błąd w specyfikacji Ada95 (a taka obowiązywała w momencie lotu
    >> Ariane 5 :D)
    >
    > W Ariane 5 nie było problemu z przekręceniem typu bazowego, tylko z rzutowaniem. I
    nawet nie dotyczyło to typu Integer.

    Ależ tam właśnie był overflow, jeden moduł (stary) pracował na
    16-bitowych danych a drugi (nowy) liczył z 32-bitową dokładnością i
    jak powiedzmy wyszło z obliczeń 16#20001 (przepełnienie) to do
    "starego" modułu trzeba było wstawić 16#7FFF (co było w innych
    miejscach zrobione na if-ach) a program wstawiał 16#20001 co stary
    moduł widział jako 16#0001 (i nie miał szans wykryć, że to wynik
    przepełnienia, bo programista "starego" modułu dopuścił jako parametr
    wejściowy dowolną liczbę całkowitą - w momencie gdy to pisał chodziło
    o dane 16-bitowe, stary moduł 16-bitowy został ponownie wykorzystany z
    komputerem 32-bitowym). Dziwi mnie tylko że ktoś te dwa "if-y" opuścił
    ze względu na potrzebę obniżenia obciążenia komputera mimo że we
    wszystkich innych miejscach pozostały (no i nawet jeśli wyrzucono
    generowanie wyjątków w czasie wykonania z tego fragmentu kodu, to
    przecież na 99% kompilator w momencie kompilacji ostrzegał o
    możliwości przepełnienia :D).

    >> Załóżmy, że sprzętowo Integer jest powiedzmy 8-bitowy
    >
    > Ale nie jest.
    >
    >> tak wiem, według specyfikacji musi być co najmniej
    >> 16-bitowy ze znakiem, ale chodzi o prostotę przykładu
    >
    > Czyli: "olejmy specyfikację w miejscu X, wtedy uda się podkreślić niedociągnięcie w
    miejscu Y".

    Ok, niech będzie dla 16-bitów (zgodnie ze specyfikacją):

    type My_Type range -25600 .. 25600;

    I mnożenie 2*25600 daje (w 16-bitach ze znakiem) -14336 (czyli wg
    'range' dopuszczalną wartość) - zasada dokładnie ta sama.

    > Krótko: masz rację.
    >

    Nie o to chodzi czy mam czy nie mam, nie potrafię po prostu zrozumieć
    jak włączenie wyjątków w czasie wykonania mogło coś zmienić w tym
    przypadku (zakładając, że kod "starego" modułu nie zostałby zmieniony)
    i dlaczego to mogło uratować sprawę, ale ok, nie ciągnę dalej tematu.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: