eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.telefonia.gsmPamięć w Androidzie › Re: Pamięć w Androidzie
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!goblin1!goblin.
    stu.neva.ru!newsfeed.neostrada.pl!unt-exc-01.news.neostrada.pl!unt-spo-a-02.new
    s.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
    From: Marek <f...@f...com>
    Newsgroups: pl.misc.telefonia.gsm
    Subject: Re: Pamięć w Androidzie
    Date: Sat, 21 Feb 2015 15:08:54 +0100
    Mime-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed
    Content-Transfer-Encoding: 8bit
    In-Reply-To: <2dgiwzv7sbct$.j9yg212mfi9t$.dlg@40tude.net>
    References: <mc0or5$v0b$1@dont-email.me>
    <a...@n...neostrada.pl>
    <mc3jev$k3u$1@dont-email.me> <54e5b202$0$2176$65785112@news.neostrada.pl>
    <mc7tqh$1g8$1@dont-email.me> <c...@4...net>
    <mc8nci$b3e$1@dont-email.me> <s...@4...net>
    <a...@n...neostrada.pl>
    <2dgiwzv7sbct$.j9yg212mfi9t$.dlg@40tude.net>
    Message-ID: <a...@n...neostrada.pl>
    User-Agent: Groundhog 2.02 Newsreader for Android.
    Lines: 30
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: apn-77-115-84-88.dynamic.gprs.plus.pl
    X-Trace: 1424527739 unt-rea-b-01.news.neostrada.pl 2187 77.115.84.88:41055
    X-Complaints-To: a...@n...neostrada.pl
    Xref: news-archive.icm.edu.pl pl.misc.telefonia.gsm:1068029
    [ ukryj nagłówki ]

    On Sat, 21 Feb 2015 11:45:27 +0100, "J.F."
    <j...@p...onet.pl> wrote:
    > No wiesz, gdyby pamiec flash byla szybka i podpieta bezposrednio pod
    > magistrale, to czemu nie ?
    > Po co przepisywac do RAM ?

    Jeśli flash stanie się w przeszłości tak samo szybki jak ram i będzie
    miał nieograniczoną liczbę zapisów to stanie się po prostu ramem
    nieulotnym, wtedy pogadamy.
    Ale problem z implementacja modelu "one memory" (bez kopiowania) nie
    jest w wolnym nośniku jakim jest flash ale w zarządzaniu i
    dystrybucji binariów.
    Aktualnie używane architektury cpu oraz kerneli nie wspierają takich
    pomysłów.
    Warstwa abstrakcji pomiędzy fs gdzie są binarki a (wirtualną)
    przestrzenią adresową cpu byłaby niepotrzebnym overkillem.
    Zachowanie swobodnej i prostej wymiany binarek jako plików w fs (jak
    jest teraz) byłoby bardzo tudne w takiej implementacji. Szybciej i
    prościej jest ładować binarki (najczęściej tylko potrzebne ich
    fragmenty) do osobnej pamięci (ram) i tam nimi zarządzać.
    Jest dziesiątki powodów, dla których kernel musi mieć procesy w
    "osobnej" pamięci (co implikuje kopiowanie z miejsca gdzie binarka
    "jest" jako kod a gdzie ma być "uruchamiana"). Stronicowanie, wymiana
    stron z swapem, prostrze (gdy są w ram) zarządzanie ochroną stron
    itd, itp. To co opisujesz bliskie jest arch. harvardzkiej,, która
    nadaje się do mikrokontrolera ale nie do implementacji współczesnego
    kernela ze wszystkimi szykanami.

    --
    Marek

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: