NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jak skutecznie i bezpowrotnie skasować pamięć flash? Metody i ich efektywność
mk
Guest
Guest
Wed Jan 24, 2007 4:50 pm
Newsuser "Marek Lewandowski" <locust@poczta.onet.pl> wrote:
Quote:
(6b/cell; niestety trzeba mieć dostęp do dokumentów IEEE)
http://www.google.com/search?q=+site:ieeexplore.ieee.org+analog+flash+memory+for+digital+storage&hl=en&lr=&start=0&sa=N
jest w produkcji?
http://www.google.com/search?q=+site:ieeexplore.ieee.org+analog+flash+memory+for+digital+storage&hl=en&lr=&start=0&sa=N
jest w produkcji?
Nie wiem. W każdym razie brane jest pod uwagę.
Quote:
Bo ostatnie, co widziałem (nie mam konta IEEE) to
był projekt struktury typu proof-of-concept, czytaj ze cztery cele na
krzyż...
I jescze (niestety również tylko dla subskrybentów IEEE):
"256-Level Non-Volatile Analog Storage Device Using EEPROM Technology"
http://www.google.com/search?hl=en&lr=&q=+site%3Aieeexplore.ieee.org+analog+eeprom+256-level
masz konto?
był projekt struktury typu proof-of-concept, czytaj ze cztery cele na
krzyż...
I jescze (niestety również tylko dla subskrybentów IEEE):
"256-Level Non-Volatile Analog Storage Device Using EEPROM Technology"
http://www.google.com/search?hl=en&lr=&q=+site%3Aieeexplore.ieee.org+analog+eeprom+256-level
masz konto?
Nie.
Quote:
Ale nieważne: już tytuł mówi o pamięci analogowej i nie używa
pojęcia bitu, tylko liczby poziomów, podejrzewam, że chodzi o
,,normalną'' pamięć analogową, czyt. 256 poziomów bez ścisłości
ile to jest 1 poziom. Do audio OK.
pojęcia bitu, tylko liczby poziomów, podejrzewam, że chodzi o
,,normalną'' pamięć analogową, czyt. 256 poziomów bez ścisłości
ile to jest 1 poziom. Do audio OK.
Jeśli rozróżniamy niezawodnie 256 poziomów, to możemy w komórce zapisać 8
bitów informacji.
Problemy z dewiacjami, dryftami związane z czasem i temperaturą?
Zarys koncepcji:
Blok danych rozszerzamy blokiem kalibracyjnym. Blok kalibracyjny składa się
z 256 komórek do którego zapisujemy, przy każdym zapisie do bloku danych, do
kolejnych komórek wartości od 0 do 255.
Działania proces odczytu, wydaje mi się, łatwo się domyślić.
(próbkowanie komórek z wyższą rozdzielczością niż 8 bitów)
To, jak napisałem, tylko koncepcja. Bardziej zaawansowana modulacja poradzi
sobie bez bloku kalibracyjnego, o ile będzie pracować na dostatecznie
długich ciągach danych (próbkowanie komórek pamięci również z
rozdzielczością wyższą niż 8 bitów).
pzdr
mk
mk
Guest
Guest
Wed Jan 24, 2007 4:51 pm
Newsuser "Marek Lewandowski" <locust@poczta.onet.pl> wrote:
Quote:
?!@?
Nagle samo to, że danych jest dużo, pozwala je przekłamać?
Łatwo dodać warstwę, która przekłamania (z akceptowalnym
prawdopodobieństwem) wyeliminuje.
no właśnie ja twierdzę, że nie tak łatwo, żeby po odjęciu
nadmiaru wymaganego przez tę warstwę zostało więcej niż powiedzmy
3-4 bity. Dla tych obecnych na rynku pamięci analogowych.
Nagle samo to, że danych jest dużo, pozwala je przekłamać?
Łatwo dodać warstwę, która przekłamania (z akceptowalnym
prawdopodobieństwem) wyeliminuje.
no właśnie ja twierdzę, że nie tak łatwo, żeby po odjęciu
nadmiaru wymaganego przez tę warstwę zostało więcej niż powiedzmy
3-4 bity. Dla tych obecnych na rynku pamięci analogowych.
Być może. Koncepcyjnie jednak poprawne.
Quote:
Tak samo jak to, że nie można z nich wyciągnąć 8bit/komórka :P
a nie. Weź tę kość i obejrzyj
1. SNR
2. sygnał przy 0oC
3. sygnał przy 100oC
z podzielenia 2 przez 3 i policzenia dewiacji już poleci parę bitów.
a nie. Weź tę kość i obejrzyj
1. SNR
2. sygnał przy 0oC
3. sygnał przy 100oC
z podzielenia 2 przez 3 i policzenia dewiacji już poleci parę bitów.
No i przejrzałem sobie notę aplikacyjną Winbonda i niestety danych takich
jak SNR nie znalałem. Z dewiacjami związanymi z temperaturą można sobie
poradzić.
Quote:
Tak samo jak to, że być może w przyszłości nie będzie można...
tego nie twierdziłem, powiedziałem tylko Leszkowi, że wątpię.
W każdym razie nie wykazałeś tego jeszcze w tej dyskusji.
Nie ja postawiłem postulat 8 bitów z ADC podpietego do pamięci
analogowej.
tego nie twierdziłem, powiedziałem tylko Leszkowi, że wątpię.
W każdym razie nie wykazałeś tego jeszcze w tej dyskusji.
Nie ja postawiłem postulat 8 bitów z ADC podpietego do pamięci
analogowej.
Ot, padła taka luźna koncepcja. Wskazałeś na problem błędów. Ja, natomiast
zwróciłem uwagę, że występowanie błędów, po odpowiednich modyfikacjach (typu
dodanie danych nadmiarowych), nie dyskwalifikuje pomysłu.
Quote:
Wiesz co, na marketingowca się kształć, dobry będziesz.
Każda pamięć jest specyfikowana względem użytecznej pojemności.
Jak masz 64k flasha, to to jest 64k do twojego użytku, a nie 64k z
których musisz sobie wyliczyć te dobre.
Przepraszam, ale źle zrozumiałem pojęcie "surowych bitów". Miałem na
myśli
"użyteczne bity".
Czyli po odjęciu korekcji błędów. Ile zostanie?
Każda pamięć jest specyfikowana względem użytecznej pojemności.
Jak masz 64k flasha, to to jest 64k do twojego użytku, a nie 64k z
których musisz sobie wyliczyć te dobre.
Przepraszam, ale źle zrozumiałem pojęcie "surowych bitów". Miałem na
myśli
"użyteczne bity".
Czyli po odjęciu korekcji błędów. Ile zostanie?
Być może parę procent mniej... co będzie skompensowane wewnętrznym
zwiększeniem ilości komórek.
Quote:
ale nie tę zapisaną informację! Na litość....
Tu dyskusja jest już czysto scholastyczna.
nie jest. Informacja może być użyteczna, jest użyteczna - dźwięk
daje się rozpoznać, szum i zniekształcenia amplitudy są filtrowane
w naszym mózgu, ale dane muszą być odczytane wiernie, więc bez tej
psychoakustycznej korekcji.
Tu dyskusja jest już czysto scholastyczna.
nie jest. Informacja może być użyteczna, jest użyteczna - dźwięk
daje się rozpoznać, szum i zniekształcenia amplitudy są filtrowane
w naszym mózgu, ale dane muszą być odczytane wiernie, więc bez tej
psychoakustycznej korekcji.
Muszą być wierne jeśli nie ma mechanizmu korekcji. Z tym nie dyskutuję.
Nie wiem jednak, dlaczego takiego mechanizmu nie można by dodać?...
Quote:
... który można, przy nieco bardziej abstrakcyjnym podejściu,
potraktować
jako liczbę.
całkowitą? Zależną od czego?
Zależną od zapisywanych danych wejściowych.
zapomniałeś o zależności od wszystkich czynników analogowych
związanych z zapisem i z samym nośnikiem zapisu. Zastanów się,
załóżmy - eksperyment myślowy - że zamrażasz wartość napięcia
0..255mV ~ 0..255. Załóż, że wzmacniacz zapisu i wzmacniacz odczytu
dopasowane są względem wzmocnienia do +/-1%. Dla sygnału analogowego
pestka, jaki masz błąd przy odczycie ,,cyfrowym''?
potraktować
jako liczbę.
całkowitą? Zależną od czego?
Zależną od zapisywanych danych wejściowych.
zapomniałeś o zależności od wszystkich czynników analogowych
związanych z zapisem i z samym nośnikiem zapisu. Zastanów się,
załóżmy - eksperyment myślowy - że zamrażasz wartość napięcia
0..255mV ~ 0..255. Załóż, że wzmacniacz zapisu i wzmacniacz odczytu
dopasowane są względem wzmocnienia do +/-1%. Dla sygnału analogowego
pestka, jaki masz błąd przy odczycie ,,cyfrowym''?
Jeśli błędy te są powtarzalne, a nie typu szum, to nie widzę przeszkody, by
wartości te odczytać dokładnie. Więcej w odpowiedzi na drugie twoje
obwieszczenie...
Quote:
Sprowadzając analizę do wartości
zapisanej zignorowałeś błędy wzmacniaczy zapisu, pojemności
pasożytniczych wokół bramki itp itd.
Potraktowałem proces zapisu-odczytu jako czarną skrzynkę.
i to jest właśnie Twój błąd, bo gdyby ten proces był tak
stabilny, jak zakładasz, to pakowalibyśmy po 7 bitów na celę. Nie
jest. Nie pakujemy.
zapisanej zignorowałeś błędy wzmacniaczy zapisu, pojemności
pasożytniczych wokół bramki itp itd.
Potraktowałem proces zapisu-odczytu jako czarną skrzynkę.
i to jest właśnie Twój błąd, bo gdyby ten proces był tak
stabilny, jak zakładasz, to pakowalibyśmy po 7 bitów na celę. Nie
jest. Nie pakujemy.
"Gdyby ten proces był tak stabilny", jak założyłem, to w prostym modelu bez
korekcji, trzeba by pakować nie 7, lecz 6 bitów na celę.
Można by mój model nieco zmodyfikować dodająć, że: średnio co 100 odczytów,
mamy odchyłkę "+/- 2", co 1000 odcztyów "+/- 3", co 10000 odczytów "+/- 4".
Z teorii o przepustowości kanału wyszło by (szacuję) wciąż ponad 7 bitów na
celę.
Przy ordynarnym podejściu już by to było tylko 4 bity na celę.
Oczywiście to tylko spekulacje, ale moim zdaniem coś pokazują.
Quote:
Nie równie dobrze. W dyskusji padła kwestja, że jeśli nie odczytamy
dokładnie tego samego, co zapiszemy, to pamięć dla danych binarnych jest
bezużyteczna.
dokładnie tak jest. Jeśli masz n bitów których nie możesz
odczytać dokładnie, to pamięć jest bezużyteczna.
dokładnie tego samego, co zapiszemy, to pamięć dla danych binarnych jest
bezużyteczna.
dokładnie tak jest. Jeśli masz n bitów których nie możesz
odczytać dokładnie, to pamięć jest bezużyteczna.
Bez korekcji tak.
Quote:
Możesz dodać
mechanizmy korekcji ale juz nie masz n bitów, więc nie możesz
twierdzić, że pamięć ma pojemność n bitów.
mechanizmy korekcji ale juz nie masz n bitów, więc nie możesz
twierdzić, że pamięć ma pojemność n bitów.
Jeśli błędy są niewielkie, to pojemność na celę spadnie tylko o jakiś tam
ułamek poniżej n.
Quote:
Owszem, odniosłeś się. Poproszę teraz, o małe co nieco, na poprcie swojej
tezy.
popatrz nieco wyżej w poście - już SNR powinien załatwić kwestię
bit na różowo, błąd wzmocnienia w funkcji temperatury jest
silniejszym czynnikiem, ale nie pamiętam, czy jest podawany w danych w
dataszicie.
tezy.
popatrz nieco wyżej w poście - już SNR powinien załatwić kwestię
bit na różowo, błąd wzmocnienia w funkcji temperatury jest
silniejszym czynnikiem, ale nie pamiętam, czy jest podawany w danych w
dataszicie.
Niestety również nie znalazłem. To dla przypadku Winbonda mogło by sprawę
rozstrzyngnąć. A może ktoś z grupowiczów ma te kostki i pokusiłby się o
pomiary?
Quote:
Czy ktoś w tej dyskusji podnosił kwestię, ze wykorzystanie pamięci
analgowej
do przechowywania danych cyfrowych ogranicza się do dodania ADC???
tak. To post, od odpowiedzi na który usiłujecie zrobić ze mnie
wielbłąda.
,,Możliwe. Firma Winbond robi dość powszechnie znane układy do
rejestracji
dżwięku, które zapamiętują analogowo wartość napięcia
poszczególnych
próbek, czyli działają jak rejestr układów
próbkująco-pamiętających
(S-H). Wystarczy dodać przetwornik C-A na wejście i A-C na wyjście i
już
mamy pamięć w której jedna komórka ma np. bajt.''
analgowej
do przechowywania danych cyfrowych ogranicza się do dodania ADC???
tak. To post, od odpowiedzi na który usiłujecie zrobić ze mnie
wielbłąda.
,,Możliwe. Firma Winbond robi dość powszechnie znane układy do
rejestracji
dżwięku, które zapamiętują analogowo wartość napięcia
poszczególnych
próbek, czyli działają jak rejestr układów
próbkująco-pamiętających
(S-H). Wystarczy dodać przetwornik C-A na wejście i A-C na wyjście i
już
mamy pamięć w której jedna komórka ma np. bajt.''
Okay.
Ale, to też tylko bardzo luźny zarys koncepcji, który, niewiedzieć czemu,
bardzo sztywno traktujesz.
Możliwe są udoskonalnia.
Quote:
ani nie daje
pojemności nawet w okolicy bajta na celę.
Pokusisz się o dowód?
jak tylko autor, lub ktoś popierający zacytowaną tezę, podeprze ją
jakąś matematyką.
pojemności nawet w okolicy bajta na celę.
Pokusisz się o dowód?
jak tylko autor, lub ktoś popierający zacytowaną tezę, podeprze ją
jakąś matematyką.
Obawiam się, że na razie nikt z nas na razie odpowiednich danych nie ma.
Postawiłeś dość twardo swoją tezę bazując jedynie na intuicji. Autor luźno
"rzucił" taką, a nie inną ilość informacji ("jedna komórka ma np. bajt")
Quote:
Dla mnie, amatora, obliczenia te wydają się być w zasięgu, pod warunkiem,
że
w nocie znajdę odpowiednie dane np. szum w sygnale po retencji (ojej!
pewnie
trzeba będzie założyć, że jest gaussowski, bo kto by tam o takim detalu
wspomniał w dokumentacji - znowu będzie można zbić całe obliczenia).
Gorzej. Poza szumem masz dryft wzmocnienia w f-cj temperatury i wpływ
jej, oraz czasu na zachowany ładunek. TEGO brakuje w przjętym modelu
zakładającym wąski błąd na poziomie 1bit.
że
w nocie znajdę odpowiednie dane np. szum w sygnale po retencji (ojej!
pewnie
trzeba będzie założyć, że jest gaussowski, bo kto by tam o takim detalu
wspomniał w dokumentacji - znowu będzie można zbić całe obliczenia).
Gorzej. Poza szumem masz dryft wzmocnienia w f-cj temperatury i wpływ
jej, oraz czasu na zachowany ładunek. TEGO brakuje w przjętym modelu
zakładającym wąski błąd na poziomie 1bit.
Myślę, że te problemy można ograniczyć zapisując jednocześnie z danymi np.
odpowiednie dane kalibracyjne. (więcej w drugim obiweszczeniu)
Quote:
Masz też stały w czasie szum wynikając z różnych parametrów cel,
ale ten jest akurat łatwo modelowalny.
Na koniec: nie oczekuję od Ciebie zrobienia tego modelu. To jest temat
na publikację naukową, a nie na posta w newsgrupie. Szacunek
5bit/celę wydaje się możliwy do zrealizowania, 4bpc uważałbym za
realistyczny. Szacując tylko po realnym stosunku sygnał/szum w takich
kościach.
ale ten jest akurat łatwo modelowalny.
Na koniec: nie oczekuję od Ciebie zrobienia tego modelu. To jest temat
na publikację naukową, a nie na posta w newsgrupie. Szacunek
5bit/celę wydaje się możliwy do zrealizowania, 4bpc uważałbym za
realistyczny. Szacując tylko po realnym stosunku sygnał/szum w takich
kościach.
Ile owy SNR wynosi w takich kościach (czy jakichkolwiek innych)? Czy
dysponujesz dokładniejszymi danymi na temat rozkładu prawdopodobieństwa tych
szumów?
Czy dysponujesz szacunkami tych parametrów w strukturach zaimplementowanych
przy użyciu dzisiejszych i przyszłych technologiach (np. wykorzystujących
polimery)?
Ja się nie upieram przy 8b/cela. Bronię jednak koncepcji, że niekoniecznie
należy się ograniczać do rozdzielczości jaką bezbłędnie daje komórka przy
bezpośrednim odczycie. Twórcy dysków twardych obecnie z tego korzystają,
choć pewnie w latach 80 ubiegłego wieku zdecydowana większość inżynierów by
wyśmiała pomysł poddawania DSP zawartości zapisanej na talerzu dysku.
pzdr
mk
Eneuel Leszek Ciszewski
Guest
Guest
Wed Jan 24, 2007 10:49 pm
"RoMan Mandziejewicz" 294981551.20070124005806@pik-net.pl
Quote:
Nie przyjmuję do wiadomosci bajtów o wielkości innej niż 8 bitów,
Z nieco innej strony: A co z transmisją, w której przesyła się mniej
niż 8 bitów jako bajt?
Na przykład 7, bo tyle wystarczy?
Wówczas na takie 7 bitów mówi się bajt siedmiobitowy. ;)
-=-
Aby było jasne -- rozumiem, o co w tym sporze chodzi. :)
Mnie uczono, że słowo to słowo, ale bajt to zawsze 8 bitów,
lecz wg mnie ta nomenklatura nie jest wcale istotna, jako
że nic z niej nie wynika. :)
--
.`'.-. ._. .-.
.'O`-' ., ; o.' leszekc@@alpha.net.pl '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;, .;. . .;\|/....
RoMan Mandziejewicz
Guest
Guest
Wed Jan 24, 2007 11:24 pm
Hello Eneuel,
Wednesday, January 24, 2007, 10:49:16 PM, you wrote:
Quote:
Nie przyjmuję do wiadomosci bajtów o wielkości innej niż 8 bitów,
Z nieco innej strony: A co z transmisją, w której przesyła się mniej
niż 8 bitów jako bajt? Na przykład 7, bo tyle wystarczy?
Wówczas na takie 7 bitów mówi się bajt siedmiobitowy.
Z nieco innej strony: A co z transmisją, w której przesyła się mniej
niż 8 bitów jako bajt?
Na przykład 7, bo tyle wystarczy?
Wówczas na takie 7 bitów mówi się bajt siedmiobitowy.
Odróżniasz znak (char) od bajtu (byte)?
Quote:
Aby było jasne -- rozumiem, o co w tym sporze chodzi.
Mnie uczono, że słowo to słowo, ale bajt to zawsze 8 bitów,
lecz wg mnie ta nomenklatura nie jest wcale istotna, jako
że nic z niej nie wynika.
Mnie uczono, że słowo to słowo, ale bajt to zawsze 8 bitów,
lecz wg mnie ta nomenklatura nie jest wcale istotna, jako
że nic z niej nie wynika.
--
Best regards,
RoMan mailto:roman@pik-net.pl
PAndy
Guest
Guest
Thu Jan 25, 2007 9:26 am
"Eneuel Leszek Ciszewski" <prosze@czytac.fontem.lucida.console> wrote in
message news:ep8kds$jse$1@flis.man.torun.pl...
Quote:
Mnie uczono, że słowo to słowo, ale bajt to zawsze 8 bitów,
lecz wg mnie ta nomenklatura nie jest wcale istotna, jako
że nic z niej nie wynika.
lecz wg mnie ta nomenklatura nie jest wcale istotna, jako
że nic z niej nie wynika.
Hm a maszyna ze slowem 12 bitow? i operujaca na 12 bitach (albo w
systemie oktalnym i wtedy teoretycznie "bajt" ma 3 bity) albo 16 bitowe
maszyny nie operujace na wielksociach mneisjzych niz 16 bitow... w tym
momencie nalezaloby wykluczyc tam stosowanie pojecia bajt w kontekscie 8
bitow...
J.F.
Guest
Guest
Thu Jan 25, 2007 11:02 am
On 23 Jan 2007 03:44:18 -0800, Marek Lewandowski wrote:
Quote:
J.F. wrote:
Zaraz chyba zawału dostanę. Nie mieszaj słowa z bajtem, bardzo proszę.
Moze nie miesza, jesli bajtu nie da sie zaadresowac
to co?
W wielu maszynach bitu nie da się zaadresować, nie zaczyna przez to
mieć innej definicji.
A co zrobisz jak maszyna ma slowo 14, 24 czy 60 bitow ?
programujesz jak gdyby nigdy nic?
Zaraz chyba zawału dostanę. Nie mieszaj słowa z bajtem, bardzo proszę.
Moze nie miesza, jesli bajtu nie da sie zaadresowac
to co?
W wielu maszynach bitu nie da się zaadresować, nie zaczyna przez to
mieć innej definicji.
A co zrobisz jak maszyna ma slowo 14, 24 czy 60 bitow ?
programujesz jak gdyby nigdy nic?
i jak dzielisz slowo na bajty ? I po co ?
J.
Marek Lewandowski
Guest
Guest
Thu Jan 25, 2007 11:16 am
On Jan 25, 11:02 am, J.F. <jfox_xnosp...@poczta.onet.pl> wrote:
Quote:
On 23 Jan 2007 03:44:18 -0800, Marek Lewandowski wrote:
J.F. wrote:
A co zrobisz jak maszyna ma slowo 14, 24 czy 60 bitow ?
programujesz jak gdyby nigdy nic?
i jak dzielisz slowo na bajty ?
J.F. wrote:
A co zrobisz jak maszyna ma slowo 14, 24 czy 60 bitow ?
programujesz jak gdyby nigdy nic?
i jak dzielisz slowo na bajty ?
nie dzielę. Po co?
Problem jest syntetyczny, bo praktycznie nie występują maszyny
dzielące słowa powiedzmy 45bitowe na np. 15bitowe podjednostki, więc
problem nazewnictwa nie występuje. W sytuacjach, gdzie może dojść
do niejednoznaczności, zazwyczaj się definiuje pojęcia, których
się używa, np. można sobie wtedy napisać, że na potrzeby tej
publikacji przyjmuje się, że słowo oznacza 45 bitów a znak oznacza
15 bitów czy 725b czy ileśtam. Ale jak nic takiego nie stoi i ktoś
napisze, że CPU pracuje ze słowem o szerokości 1.5 bajtu, to oznacza
to, że słowo ma 12bit...
To _trochę_ tak, jakby upierać się, że kilogram może mieć więcej
lub mniej niż 1000 gramów, bo są produkty pakowane tylko po 500g...
--
Marek Lewandowski
ICQ#/GG#: ask per mail. mail: locust[X]poczta/onet/pl
my gallery: http://www.pbase.com/mareklew
my kind-of-a-blog: http://lockaphoto.stufftoread.com
PAndy
Guest
Guest
Thu Jan 25, 2007 11:46 am
"Marek Lewandowski" <locust@poczta.onet.pl> wrote in message
news:1169720164.620059.292650@v45g2000cwv.googlegroups.com...
nie dzielę. Po co?
Problem jest syntetyczny, bo praktycznie nie występują maszyny
dzielące słowa powiedzmy 45bitowe na np. 15bitowe podjednostki, więc
problem nazewnictwa nie występuje. W sytuacjach, gdzie może dojść
do niejednoznaczności, zazwyczaj się definiuje pojęcia, których
się używa, np. można sobie wtedy napisać, że na potrzeby tej
publikacji przyjmuje się, że słowo oznacza 45 bitów a znak oznacza
15 bitów czy 725b czy ileśtam. Ale jak nic takiego nie stoi i ktoś
napisze, że CPU pracuje ze słowem o szerokości 1.5 bajtu, to oznacza
to, że słowo ma 12bit...
uj zebys sie nie zdziwil - w dawnym ZSRR pewnie dalej stoja cuda
pracujace na 12bitowych bajtach/slowach operujace na liczbach w systemie
oktalnym...
robili takie maszyny na procesorach segmentowych w technologii ECL do
przetwarzania sygnalow - namiastki DSP lat 80 w ZSRR...
Marek Lewandowski
Guest
Guest
Thu Jan 25, 2007 12:10 pm
On Jan 25, 11:46 am, "PAndy" <pandrw_cutth...@poczta.onet.pl> wrote:
Quote:
"Marek Lewandowski" <loc...@poczta.onet.pl> wrote in messagenews:1169720164.620059.292650@v45g2000cwv.googlegroups.com...
uj zebys sie nie zdziwil - w dawnym ZSRR pewnie dalej stoja cuda
pracujace na 12bitowych bajtach/slowach operujace na liczbach w systemie
oktalnym...
uj zebys sie nie zdziwil - w dawnym ZSRR pewnie dalej stoja cuda
pracujace na 12bitowych bajtach/slowach operujace na liczbach w systemie
oktalnym...
przecież nie pisałem, że nie występują, tylko że prawie nie
występuja. Jest ich relatywnie niewiele i ludzie, którzy je
programują, zazwyczaj nie zawracają sbie głowy rozważaniem, czy to
dobrze, że słowo nie jest podzielne przez bajt, czy nie...
Quote:
robili takie maszyny na procesorach segmentowych w technologii ECL do
przetwarzania sygnalow - namiastki DSP lat 80 w ZSRR...
przetwarzania sygnalow - namiastki DSP lat 80 w ZSRR...
Pamiętam jeszcze eksperymentalne procesory: ,,szeregowy'' i
,,równoległy'' będące częścią jakiejś pracy doktorskiej z
dziedziny przetwarzania danych, jeden CPU działał na 1bit szerokości
szyny, przez co wprawdzie rdzeń był złożony (dane i instrukcje
nadchodziły szeregowo), ale szyna na zewnątrz mogła być taktowana
absurdalnie wysoko (bo nie było problemu nierównomierności czasów
transportu dla poszczególnych bitów), drugi design upraszczał
maksymalnie rdzeń: obsługiwane były tylko 2 instrukcje (bodajże XOR
i NAND) kodowane na jednym bicie i szyna danych szeroka na ile się da.
Taktowanie na zewnątrz było niskie, za to rdzeń stanowił banalny
układ kombinacyjny i mógł być taktowany ad absurdum. W zależności
od stosunku stopnia skomplikowania operacji i ilości danych do
przetworzenia optimum wahało się między tymi ekstremami...
--
Marek Lewandowski
ICQ#/GG#: ask per mail. mail: locust[X]poczta/onet/pl
my gallery: http://www.pbase.com/mareklew
my kind-of-a-blog: http://lockaphoto.stufftoread.com
J.F.
Guest
Guest
Thu Jan 25, 2007 1:21 pm
On 25 Jan 2007 03:10:21 -0800, Marek Lewandowski wrote:
Quote:
On Jan 25, 11:46 am, "PAndy" <pandrw_cutth...@poczta.onet.pl> wrote:
uj zebys sie nie zdziwil - w dawnym ZSRR pewnie dalej stoja cuda
pracujace na 12bitowych bajtach/slowach operujace na liczbach w systemie
oktalnym...
przecież nie pisałem, że nie występują, tylko że prawie nie
występuja. Jest ich relatywnie niewiele i ludzie, którzy je
programują, zazwyczaj nie zawracają sbie głowy rozważaniem, czy to
dobrze, że słowo nie jest podzielne przez bajt, czy nie...
uj zebys sie nie zdziwil - w dawnym ZSRR pewnie dalej stoja cuda
pracujace na 12bitowych bajtach/slowach operujace na liczbach w systemie
oktalnym...
przecież nie pisałem, że nie występują, tylko że prawie nie
występuja. Jest ich relatywnie niewiele i ludzie, którzy je
programują, zazwyczaj nie zawracają sbie głowy rozważaniem, czy to
dobrze, że słowo nie jest podzielne przez bajt, czy nie...
Tak czy inaczej - problem sie zaczal w czasach gdy stalo ich wiecej,
i wtedy jeszcze nie bylo takie pewne czy "byte" to 8 bitow
czy nie. Stad pomysl oktetu.
Za http://en.wikipedia.org/wiki/Byte
Originally a variable number of bits smaller than a word [...]
History
The term byte was coined by Werner Buchholz in 1957 during the early
design phase for the IBM Stretch computer. Originally it was defined
in instructions by a 4-bit byte-size field, allowing from one to
sixteen bits (the production design reduced this to a 3-bit byte-size
field, allowing from one to eight bits in a byte); typical I/O
equipment of the period used six-bit units. A fixed eight-bit byte
size was later adopted and promulgated as a standard by the System/360
[..]
A teraz wejdzie Unicode i bajty znikna :-)
Quote:
Pamiętam jeszcze eksperymentalne procesory: ,,szeregowy'' i
,,równoległy'' [...]
,,równoległy'' [...]
O ile pamietam to byly w produkcji maszynki mikroprogramowane,
gdzie sie w miare latwo wpisywalo dosc dowolny procesor.
J.
PAndy
Guest
Guest
Thu Jan 25, 2007 1:37 pm
"Marek Lewandowski" <locust@poczta.onet.pl> wrote in message
news:1169723421.148277.74060@m58g2000cwm.googlegroups.com...
On Jan 25, 11:46 am, "PAndy" <pandrw_cutth...@poczta.onet.pl> wrote:
Quote:
"Marek Lewandowski" <loc...@poczta.onet.pl> wrote in
messagenews:1169720164.620059.292650@v45g2000cwv.googlegroups.com...
uj zebys sie nie zdziwil - w dawnym ZSRR pewnie dalej stoja cuda
pracujace na 12bitowych bajtach/slowach operujace na liczbach w
systemie
oktalnym...
messagenews:1169720164.620059.292650@v45g2000cwv.googlegroups.com...
uj zebys sie nie zdziwil - w dawnym ZSRR pewnie dalej stoja cuda
pracujace na 12bitowych bajtach/slowach operujace na liczbach w
systemie
oktalnym...
przecież nie pisałem, że nie występują, tylko że prawie nie
występuja. Jest ich relatywnie niewiele i ludzie, którzy je
programują, zazwyczaj nie zawracają sbie głowy rozważaniem, czy to
dobrze, że słowo nie jest podzielne przez bajt, czy nie...
Chodzi o to by ujednolicic pojecia - jesli mamy dwoch gosi ktorzy pod
pojeciem bajt moga co innego widziec to lepeij definiowac czytelnie -
ale jak mowie dyskusja tu juz na poziomie mocno akademickim sie toczy...
Quote:
robili takie maszyny na procesorach segmentowych w technologii ECL do
przetwarzania sygnalow - namiastki DSP lat 80 w ZSRR...
przetwarzania sygnalow - namiastki DSP lat 80 w ZSRR...
Pamiętam jeszcze eksperymentalne procesory: ,,szeregowy'' i
,,równoległy'' będące częścią jakiejś pracy doktorskiej z
dziedziny przetwarzania danych, jeden CPU działał na 1bit szerokości
szyny, przez co wprawdzie rdzeń był złożony (dane i instrukcje
nadchodziły szeregowo), ale szyna na zewnątrz mogła być taktowana
absurdalnie wysoko (bo nie było problemu nierównomierności czasów
transportu dla poszczególnych bitów), drugi design upraszczał
maksymalnie rdzeń: obsługiwane były tylko 2 instrukcje (bodajże XOR
i NAND) kodowane na jednym bicie i szyna danych szeroka na ile się da.
Taktowanie na zewnątrz było niskie, za to rdzeń stanowił banalny
układ kombinacyjny i mógł być taktowany ad absurdum. W zależności
od stosunku stopnia skomplikowania operacji i ilości danych do
przetworzenia optimum wahało się między tymi ekstremami...
pomyslow bylo wiele - sa proof of concept dzialajcego CPU ktory ma jedna
intrukcje skoku warunkowego...
A takie DSP robili np rosjanie - jeden, jedno bitowy motylek FFT w
ukladzie scalonym...nie mam przy sobie ichniego katalogu wiec symbolu
nie podam...
Adam Jurkiewicz
Guest
Guest
Mon Jan 29, 2007 3:25 pm
Marek Lewandowski wrote:
Quote:
Słowo najczęściej jest wielokrotnością bajtu, wyjątki są rzadkie
(np. PIC-e mają 12-bit słowo programu).
(np. PIC-e mają 12-bit słowo programu).
Dla uzupełnienia, 14 i 16 bitowe również.
sword
--
e-mail: sword@wywalic.ajpic.zonk.pl
www: http://ajpic.zonk.pl/
gg#: 1781804
elektroda NewsGroups Forum Index - Elektronika Polska - Jak skutecznie i bezpowrotnie skasować pamięć flash? Metody i ich efektywność