TwojePC.pl © 2001 - 2024
|
|
A R C H I W A L N A W I A D O M O Ś Ć |
|
|
|
Deklarowanie typu danych o innej ilości bitów niż 8/16/32/64/... , myszon 18/12/17 14:12 Zastanawia mnie jak wygląda w różnych językach programowania deklaracja typu o innej ilości bitów niż 2^n. Chciałbym mieć np. dużą listę integerów, każdy o szerokości np. 12 bitów (z przetwornika ADC). Oczywiście mogę zrobić cast na Int16, ale przez to 1/8 pamięci będzie niewykorzystana.
Pomijam tu kwestie szybkości operacji na takich danych i to że pewnie musiałbym napisać od nowa +, *, itp. Chodzi mi tylko i wyłącznie o składowanie takich danych. Typowo akademickie pytanie.
Czy języki programowania, których używacie, umożliwiają deklarację takiego typu?- a 12 , Killer 18/12/17 14:40
to nie jest czasem 8 +4 , wtedy oszczędzasz pamięć trzeba by tylko poprawnie robić przeniesienia w dodawaniu :)Kiedyś normą był ogół a nie margines... - Pytanie , ligand17 18/12/17 14:48
czy faktycznie jest sens oszczędzać 4 bity pamięci kosztem dodatkowego nakładu pracy potrzebnego na redefinicję działań arytmetycznych?
Może w specyficznych zastosowaniach faktycznie jest taka potrzeba ale zapewne są do tego odpowiednie języki/procedury. Na co dzień chyba ilość pamięci dostępna dla aplikacji nie powinna być problemem...- jest sens , myszon 18/12/17 15:08
bo do zapamiętania będzie np. setka TB danych. Paza tym "typowo akademickie pytanie".- Czy ja wiem , ligand17 19/12/17 14:39
Jakoś nie potrafię sobie wyobrazić sytuacji, gdzie przetwarzasz setki TB danych w programie pisanym samodzielnie.
Chyba, że przygotowujesz oprogramowanie do odbioru i obróbki wstępnej danych doświadczalnych w CERNie :-)- pracuję na uniwerku , myszon 19/12/17 16:54
recenzuję pracę gdzie zbierają dużo danych. Sami też piszemy soft do układów monitorowania farm wiatrowych. Właśnie takie zastosowania jak ty opisujesz mamy. - w excelu na przyklad... , metacom 20/12/17 11:25
...jak piszesz macro i robisz skomplikowane operacje to sie bardzo przydaje...
Największą sztuczką Szatana jest to,
że ludzie w niego nie wierzą. - Eee... Że ke? , ligand17 20/12/17 12:29
Setki TB w Excelu???
- dodatkowo , myszon 18/12/17 15:09
co jak będę miał np. 3 bitowe danych a najmniejszy dostępny Int będzie Int16.- W takim wypadku , ligand17 19/12/17 14:37
to chyba trzeba zmienić język programowania - przecież już w najstarszych językach jak C czy Fortran można deklarować rozmiar zmiennych...- Przeczytaj mój post dokładnie , myszon 19/12/17 16:56
Chcę się dowiedzieć jak zadeklarować taki typ w różnych językach programowania. Jak umiesz zadeklarować taki typ w C lub FORTRANIE to dawaj.- Generalnie wiekszosc jezykow albo skrzętnie ukrywa jak obsluguje poszczegolne typy danych , ptoki 19/12/17 17:45
albo bazuje na 8 bitowych bajtach (z wyjatkiem maszyn gdzie jest np. 12 bitowy "bajt" - nie pamietam nazwy)
W C sie nie da zrobic 10-12 bitowego typu danych (tak aby wykorzystać te 1/4 bitów na
kolejna zmienna)
https://stackoverflow.com/...-field-data-type-in-c
W fortranie też nie rozdrabiaja sie na takie detale:
https://www.tutorialspoint.com/...n_data_types.htm
Pytanie zadales ciekawe.
Jesli warunki w programie pozwalaja to mozna by zrobic bitowa kolejke fifo i wrzucac w nia paczki po 12 bitów. Jakby to wepchnąć w obszar pamięci na zasadzie cyklicznego pierścienia (nie pamietam nazwy) to masz prawie darmo 1/4 pamieci wiecej.
W skrócie:
Prosto sie nie da. W ogólności sie da ale sporo zależy od tego co z danymi robisz.
- Rily??? , ligand17 19/12/17 17:49
W Fortranie to było prosto:
INTEGER x, y, z
INTEGER(4) i4
INTEGER(8) i8
Chyba działały też INTEGER(1) i INTEGER(2), ale to już zależnie od używanego kompilatora.
W C nie pisałem specjalnie dużo więc nie pamiętam już dokładnie wszystkich sztuczek, ale tutaj masz niezłą dyskusję na początek:
https://stackoverflow.com/...ne-a-one-bit-variable- Chiba jest ciekawiej: , ptoki 19/12/17 18:30
This answer starts off wrong: Fortran variables are not defined in terms of the number of bytes they occupy. The kind selectors, the integers in an expression such as integer(8) or real(4), simply identify one of the kinds supported by the compiler. The NAG Fortran compiler, for example, defaults to integer(2) for 4-byte integers and integer(3) for 8-byte integers. It is common for compilers to use kind selectors which match the number of bytes used, but it is not required by the standard.
https://stackoverflow.com/...-the-smallest-integer
- To ma sens , ligand17 19/12/17 20:04
ja uczyłem się programować w zamierzchłych czasach, kiedy standardem był Fortran77. Wtedy kompilatorów było ze 3 i każdy miał troszkę inną specyfikę. Pamiętam, że przy przejściu na F90 było dużo smaczków i wiele nowych kompilatorów (pojawiły się np. M$, Compaq) i czasem było zdziwienie, że zmienne zachowują się inaczej.
Ale wtedy postęp był tak szybki, że nikt nie zawracał sobie głowy wyciskaniem ostatnich soków z maszyny - przez czas wymagany na dopracowanie kodu pojawiały się procesory o tyle szybsze, że zysk z tytułu optymalizacji kodu był niwelowany z nawiązką przez dodatkowe MHz CPU i MB RAMu.- no wlasnie. te 12 bitów per zmienna wygląda mi bardziej na zagadnienie , ptoki 19/12/17 21:42
akademickie niż realny use case.
te 1/4 pamięci to z jednej strony niemało a z drugiej za pare pln wiecej per sztuka mozna mieć lepszy mikrokontroler.
A w przypadku jakichś fpga (np. poganianych przez labview) to chyba zupełnie inna bajka.
Ale temat ciekawy :)- Ale tu nie chodzi tylko o mikroprocesory , myszon 19/12/17 21:49
To może być pod Windą lub Linuxem też.- No fajnie. Ale jaki jest cel tego ćwiczenia? , ptoki 19/12/17 22:13
Bo to że sie da to wiadomo. To wiedza na poziomie gimbazy czy technikum.
My tu magii nie odkrywamy. Ciekawi mnie co jest powodem ze szukasz takiego rozwiązania.
Czyżbyś pisał dyplomówke? :)
- cel ćwiczenia , myszon 20/12/17 09:50
jest powiększenie mojej wiedzy o programowaniu. Jeśli będę w stanie zadeklarować typ np. Int12 albo Int13 to będę mógł ten typ wykorzystać do przechowania danych dwunasto- albo trzynastobitowych bez marnowania pamięci. Jeśli jest to wiedza na poziomie gimnazjum to ją tu zaprezentuj.
Na razie jedyną metodą którą znalazłem to zaalokowanie bufora pamięci i samodzielne dzielenie danych na bajty. Wolałbym rozwiązanie, w którym mogę zrobić macierz data[10(sizeof(Int12))], która zaalokuje mi dokładnie 120bitów na dane. Język programowania nie jest tu istotny. Chciałbym wiedzieć czy w dowolnym języku na dowolnej platformie z jakimkolwiek kompilatorem da się to zrobić.- Rozpisalem ci co trzeba zrobic. , ptoki 20/12/17 10:41
Ale nie da sie tego zrobic tak jak bys chciał.
Pisać kodu ci nie bede bo pożytek dla mnie z tego żaden, ty też sie nie nauczysz od patrzenia. A jednak chwile by popisać trzeba.
No i jak napisałem wcześniej, to jak zrobic to aby mieć dane 12 czy 13 czy 57 bitowe zależy od zastosowania. Czasem lepsza stabilna tabelka i offsety a czasem fifo.
W praktyce nikt tego nie potrzebuje i albo zmienia platforme albo pisze sobie program tak aby sie zmieściło korzystajac z innej struktury danych... - podalem , endern 20/12/17 11:00
Ci poniżej jak to się robi.
Ja to tak realizowałem w asemblerze. Ponizej masz przykład w C.
Kwestia napisania metod do obsługi.
- i tu , ptoki 19/12/17 18:31
http://earth.uni-muenster.de/...x-um/dfum_034.html
- no dajcie spokój, tylko ja takie rzeczy miałem na studiach :D? , endern 19/12/17 21:49
https://www.cprogramming.com/...ise_operators.html
Z tego co pamiętam trzepaliśmy takie rzeczy na laborce z asemblera. Jak się trochę tego poprogramowało, to było to w sumie całkiem intuicyjne.
Takie rzeczy to generalnie najlepiej robic jak najbardziej niskopoziomowo.
Tak jak już mówiłem, wszystko jest tylko kwestia kosztu związanego z takim przetwarzaniem.
- ograniczenia technologii , vaneck 18/12/17 16:43
jeżeli chcesz cyfrowo zapisać to nie masz wyboru. W dwóch bitach zapiszesz trzy cyfry naturalne dodatnie i zero. Dla dziesięciu cyfr arabskich potrzebujesz 2^4 bo 2^3 to za mało. I co zrobisz jak nic nie zrobisz?A little less conversation, a little more action
please - ... , rzymo 18/12/17 17:47
Jest coś takiego jak pola bitowe. Tylko do końca to też nie rozwiązuje problemu zajętości pamięci, bo jak pola nie pokryją się z podstawowymi typami danych, to kawałek przestrzeni adresowej i tak zostanie pusty.
Wspomniane przez Ciebie 12-bitowe liczby i tak zajmą 16 bitów / 2 bajty (* = pamięć zajęta, 0 = pamięć wolna):
************0000 | ************0000 | itd.
W idealnym przypadku wartości muszą wypełniać w całości typ wielkości podstawowej, czyli np. osiem dwu bitowych wartości w miejscu jednego podstawowego dwu bajtowego INT.
Mogą być też rozwiązania bliskie ideałowi, czyli np. kombinacja pól 1 bit + 4 bit + 8 bit + 4 bit - prawie idealnie się mieszczą w 2 bajtowym słowie, będzie strata 1 bitu:
144448888888844440 | 144448888888844440 | itd.
Ma to sens, jeśli dane są kilku bitowe i liczone w milionach / miliardach sztuk - oszczędność zajętości pamięci będzie konkretna...... ITX ... - Miało być w głównym , rzymo 18/12/17 17:48
raz dwa trzy... ITX ... - to to ja wiem , myszon 18/12/17 18:45
np. ARGB jest kodowane jako 2+10+10+10 co daje wygodne 32 bity. Ale przecież nic w komputerze nie ogranicza mnie do operacji tylko na np. 32/64bit liczbach.
- Ano wygląda w większosci przypadków tak samo. Czyli , ptoki 18/12/17 17:49
Masz standardowe typy dla danego kompilatora i platformy plus mozesz sam sobie napisać odpowiedni typ który ci owinie i odwinie ten fikusny typ.
Bo ktoś te operacje musi robic.
Jak oplaca ci sie zyskać te 1/4 bitów poświęcając sporo cykli CPU to nie widze problemu aby to ogarnąć.
Ale liczę że impakt będzie spory.
Ale mozesz tez zrobic hybrydowo ( wszelkie odmiany PCM-a) I te droge bym ci polecał choć to sporo zalezy od operacji jakie na tych danych czynisz (np. czy dane są wymagane random access czy zazwyczaj czytane sekwencyjnie).
- a czy masz jakiekolwiek przykłady , myszon 18/12/17 19:10
jak to może wyglądać i dla jakiego kompilatora. Bo zakładam że w embedded C takie coś może być łatwiej zrobić niż w Rubym.
Zakładam, że zwykle w C malloc nie da mi np. zaalokować 12 bitów, ale zaokrągli do 16.- Nooo nie az tak fajnie jak podejrzewasz. , ptoki 19/12/17 17:34
Nie zaalokujesz mniej niż bajt. A i tak jak alokujesz bajt to tak naprawde alokujesz więcej tylko OS mowi ze daje bajt a tak naprawde daje 1kb czy ile tam mu sie podoba (do sprawdzenia w dokumentacji konkretnego kompilatora). Dlatego programy nie wywalaja sie jak o jeden bajt wyjedziesz za tabelke tylko zazwyczaj trzeba nieco dalej pójść.
Tak więc to co kombinujesz to trzeba zrobić samodzielnie w oparciu o to co jest standardowo. czyli po kolei:
-alokujesz tabelke na Twoje dane
-tabelke opisujesz jej wielkoscia i iloscia bitow (u ciebie 12)
-obslugujesz ją za pomocą dedykowanych funkcji (read, write) które wyciagaja upakowane dane do postaci standardowej (16 bitów)
-do tych dwu funkcji tworzysz funkcje pomocnicza ktora przelicza offset z rozmiaru 12 bitowego na 16 bitowy i wypakowuje te 12 bitów tak aby sie wartośc zgadzała w postaci 16 bitowej i w druga strone.
Cale przeliczenia robisz w 16 bitach i dbasz o to aby wynik tez sie w tym zmiescil.
Przykladu na to nie mam bo nigdy mi nie bylo to potrzebne ale idea jest podobna do operowania rekordami. czyli Struktura danych plus obslugujace to funkcje.
Sens oszczedzania tej 1/4 bajtów jest kiedy masz tych danych naprawde duzo albo naprawde malo pamieci.
Daj znać który z tych przypadków wystepuje u ciebie.
Tak czy siak za te upakowanie w pamieci zaplacisz cyklami cpu. W praktyce prosciej przerobic projekt na wieksza atmege ;)
- no... , endern 18/12/17 18:26
oprogamowywujesz to po prostu, implementując klasę i metody odczytu.
Przecież to jak interpertujesz bity i bajty to twoja sprawa.
Kwestia tylko jak kosztowne to będzie obliczeniowo.
- kosztowne pewnie nie bo , ptoki 18/12/17 18:59
mając tablice łatwo można wyliczyć jak ustawić bajty przy konwersji i o ile przesunąć w prawo/lewo.
Drogo to nie jest...
- W kompilatorach na procesory rodziny 8051 masz typ bit. , jenot 18/12/17 20:43
:-)Mój podpis max 100 zanaków,
zabroniony spam oraz reklama. - Wyglądało to tak: , jenot 18/12/17 20:47
/* Pin assigments 8051 processor */
/* (c) 1996 by OlafSoft */
#ifndef _PORTS51_H_
#define _PORTS51_H_
/* P0 */
sbit P0_7 = 0x87;
sbit P0_6 = 0x86;
sbit P0_5 = 0x85;
sbit P0_4 = 0x84;
sbit P0_3 = 0x83;
sbit P0_2 = 0x82;
sbit P0_1 = 0x81;
sbit P0_0 = 0x80;
Mój podpis max 100 zanaków,
zabroniony spam oraz reklama.
- zmień ADC , Adex1234 23/12/17 14:37
na 16 bitowy i problem z głowyhttp://hwbot.org/user/adex1234 |
|
|
|
|
All rights reserved ® Copyright and Design 2001-2024, TwojePC.PL |
|
|
|
|