Szukam sobie jakiegoś języka programowania, którego mógłbym się nauczyć. Chcę czegoś dość nisko związanego ze sprzętem i o praktycznych zastosowaniach. Przy okazji musi być jeszcze darmowy (w tym do celów komercyjnych) kompilator działający pod Linuxem AMD 64. Język nie musi być popularny.
Do tej pory bawiłem się trochę C++, ale chcę czegoś innego. Większość języków, o jakich się dzisiaj słyszy (C#, Java, Python) są interpretowane, a to mnie w sumie nie interesuje.
Od kiedy Java jest jezykiem interpretowanym? 
ANSI C? Chyba tylko w tym licząc znane języki można pisać wystarczjąco niskopoziomowo i obsługiwać sprzęt.
Składnia C jest dostępna w C++, więc nie spełnia moich warunków.
Java zaś jest interpretowana od zawsze. Wszystko, co działa na różnych procesorach, musi być interpretowane, ponieważ nie może być w kodzie maszynowym.
Originally posted by Big_Z:
Java zaś jest interpretowana od zawsze.
Tak, a pierwszym powojennym krolem polski byl Tadeusz Kosciuszko
Trolenijuszu!
Nie interpretowane. Interpretowany to jest bash( bo przez interperter wykonywany). Java jest kompilowana do bcodu bytecodu, podobnie si szarp.
W sam raz dla Ciebie niskpoziomowy i malo popularny (przepraszam wszystkich urazonych) jest asembler. Polecam zeby bylo ciezej jakis asembler kostek nie koniecznie majacych zwiazek z PC bezposrednio np co uC AVR.
http://pl.wikipedia.org/wiki/Avr
Sam sie ostanio przymierzam wiec mozemy sie posilowac
Originally posted by http://pl.wikipedia.org/wiki/Java:
Java jest językiem tworzenia programów źródłowych kompilowanych do kodu bajtowego, czyli postaci wykonywanej przez maszynę wirtualną.
Java jest przenośna nie dlatego że jest interpretowana (co nie jest prawdą i tak) tylko dlatego że programy uruchamiane są na wirtualnej maszynie... Jest to typ języka "Write once - run anywhere"...
Dla mnie, w tym konkretnym wypadku, językiem kompilowanym jest dowolny język, który można skompilować do kodu maszynowego AMD 64. Wszystkie pozostałe uważam za języki interpretowane.
Java, podobnie jak języki .Net, jest torchę problematyczna w tej klasyfikacji. To takie ogniwo pośrednie między językami interpretowanymi, a kompilowanymi. W każdym razie, jeśli założyć, że Java jest kompilowana do postaci kodu maszynowego, to interpretowany jest właśnie ów kod maszynowy, wirtualna maszyna to taki właśnie interpreter.
Jeśli chodzi zaś o asembler, aż tak nisko nie zamierzam jeszcze iść. Poza tym język może być popularny, pisałem tylko, że nie musi.
A co złego jest w "C" ?
Wady C i C++
1. Nazwy elementarnych typów są niespójne. Czasami stanowią jeden wyraz, czasami dwa, czasami trzy... I nie wiadomo, co znaczą.
2. Mało czytelna składnia.
3. Składnia jest składnią C, a ja chcę poznać coś nowego.
1. Jakas tam wada jest, ale bez przesady.
2. Dla innych java jest mało czytelna
3. Cobol
4. Chyba koledze sie nudzi.
Originally posted by Vambeer:
4. Chyba koledze sie nudzi.
Pewnie nie nam oceniać, ale... podobnie pomyślałem
Big Z nie myślałeś o doskonaleniu swoich umiejętności w znanym już języku, zamiast uczenia się podstaw kolejnego? Na pewno sam znasz wiele otwartych projektów, których dzieła wykorzystujesz. Może byś się do którejś grupy developerów dołączył?Ciekawe doświadczenie może się z tym wiązać. Ja pisałem już wszelkiej maści programy: prostej gry, komunikatory, bazy danych, a wgryzienie się w czyjś kod i poprawienie najprostsego błędu w napisanym już programie potrafi być sporym wyzwaniem
Originally posted by Vambeer:
4. Chyba koledze sie nudzi.
Dokladnie, kolega pozjadal wszelkie rozumy (Java, podobnie jak języki .Net, jest torchę problematyczna w tej klasyfikacji. - jeszcze raz powtarzam java jest , byla i bedzie jezykiem kompilowanym niezaleznie od dzialania wirtualnej maszyny )
Po twierdzeniach wnioskuje, ze nasz Big_Z ma doswiedczenie ale tylko w pisaniu prostych aplikacji tudzień skryptów/skrypcikow na potrzeby wlasne.
Originally posted by Big_Z:
Wady C i C++
...
2. Mało czytelna składnia.
Chyba brakuje Ci dostatecznej wiedzy na temat. Kursy internetowe w tym nic nie pomoga.
Fakt, mogę powiedzieć, że mi się nudzi. Wolę jednak określenie, że chcę zdobyć nowe doświadczenie dla zdobywania nowego doświadczenia. Co w tym złego? Może mnie to bawi? A że doświadczenie może mi się nie przydać... Nie chcę popadać w skrajny utylitaryzm.
Jeśli chodzi o większe projekty i mój w nich udział. Do czasu, aż nie wykształcę sobie spójnego stylu programowania, w dodatku bardzo czytelnego, nie czuję się na siłach współpracy przy nich. Poza tym nie znalazłem sobie jeszcze pola, w którym chciałbym się rozwijać. Programista, który tylko sporadycznie wysyła swoje drobne rozszerzenia do projektu, nie jest wiele wart.
Na chwilę obecną nie chcę pogłębiać umiejętności związanych z C++. Nie wiem, czy chcę iść w tym kierunku. Muszę jeszcze zdobyć trochę doświadczenia, aby się dowiedzieć, co mi wychodzi, co mi sprawia przyjemność.
Jeśli chodzi o Javę, nie jest to język stworzony do kompilowania do kodu maszynowego fizycznie istniejących procesorów. Interesuje mnie język, który do takiego kompilowania został stworzony, a w dodatku kod wynikowy jest całkiem wydajny. Nie znam ogólnie przyjętego terminu dla języka klasy Java, ale nie jest to klasyczny język kompilowany, w przeciwieństwie do C++.
Big ! Wszystko przed Toba tyle ze nie ma co o tym pisac po forumach. Jak chcesz byc programista to programuj programuj programuj programuj. Jezyk jest naprwde rzecza wtorna. Tymbardziej wtorna rzacza jest do czego dany jezyk jest kompilowany. Zaraz minie 5 lat jak programista jestem zawodowo. Z pewnej niewielkiej ale jednak perspektywy widze ze do jezyka nie nalezy sie super przywiazywac. Czasem projekty wymagaja uzycia czegos natywnie kompilowanego czasem pseudokodu, czasem trzeba skrypt w baszu zrobic taki do hakowania serwera np: ./hakuj_server . Jestem zwolenikiem jezykow C/C++ a nawet asembler jako jezyki pierwsze, jezyki ktore naucza cie architektury na ktorej pracujesz, poszanowania pamieci i zasobow itp. Jak juz masz pewnego skila i wiesz co to wskaznik i graf to przesiadz sie na jave c# czy python - jezyki ktore pozwalaja skupic sie na problemie - algorytmie niejako od strony biznesowej i nie musisz sie bujac z zarzadzaniem pamiecia a bujasz sie z tylko z iloscia ram maszyny produkcyjnej . Mozesz tez zostac przy c/c++, zaczac bawic sie boostem, ATL, MFC czy (Boze Bogoslaw Opere) np QT . Drog jest naprawde wiele i nie masz co szukac na sile JEZYKOW KOMPILOWANYCH POD AMD64 BO TYLKO TAKIE UWAZASZ ZA KOMPILOWANE . Jesli masz byc devem to nim bedziesz, nie walcz z plywami, nie plyn pod prad, tao Cie odnajdzie.
Ja ze swojej strony polecam Adę, bardzo porządny, choć niestety mało znany język programowania. Cechy:
- kompilowany do kodu maszynowego
- czytelna składnia
- rozbudowany system typów
- wbudowana obsługa wątków
- ...i wiele innych
Warto poznać Adę, bo wyrabia dobry styl programowania i pozwala dostrzec, czego brakuje językom C/C++ (niczego im nie ujmując). Tutaj jest przewodnik dla programistów C/C++.
Originally posted by blysk:
Ja ze swojej strony polecam Adę,
Bylem na Twojej stronie wlasnie przed chwila (ta z profilu) i nie ma tam slowa o Adzie! Wiec nie pisz ze swojej strony. Co do samej Ady to ponoc nawet do wojskowych zastosowan byla polecana? Dobrze kojarze?
Właśnie chcę się trochę nauczyć bardziej rozumieć wnętrze komputera, nauczyć się świadomego zarządzanie pamięcią operacyjną. Chcę więc język kompilowany, a że z różnych powodów byłem zmuszony kupić procesor, który rozumie kod maszynowy AMD 64...
Ada zaś na pierwszy rzut mojego oka jakoś tak mało różni się od C... Jakieś detale?
Originally posted by elpako:
Nawet jeżeli zwrot ze swojej strony jest niezbyt zgodny z zasadami języka polskiego, to taka uwaga napisana przez człowieka lekceważacego zasady polskiej pisowni wygląda bardzo dziwnie.Wiec nie pisz ze swojej strony.
Originally posted by Big_Z:
Ada zaś na pierwszy rzut mojego oka jakoś tak mało różni się od C... Jakieś detale?
Największą różnicą jest silna typizacja (która umożliwia wykrycie wielu błędów już na etapie kompilacji) oraz rozbudowany system typów. W Adzie można tworzyć nowe typy np:
type Wiek is range 1 .. 100; type Procent is range 1 .. 100;Następnie, gdy omyłkowo przypieszemy do siebie zmienne niezgodnych ze sobą typów, błąd zostanie wykryty:
wiek1 : Wiek := 3; p1 : Procent := wiek1; -- Błąd na etapie kompilacjiMożemy też budować typy pochodne, które są zgodne ze swoim "rodzicem":
type Wiek is range 1 .. 100; type Wiek_przedszkolny is range 1 .. 6; wiek1 : Wiek := 4; wiek2 : Wiek_przedszkolny := wiek1; -- Wszystko w porządkuAda to również język zorientowany obiektowo i umożliwia dziedziczenie, polimorfizm oraz enkapsulację danych (nawet większą niż w C++).
Następną dużą różnicą jest obłsuga wielowątkowości. Tworzenie wątków (tasks), różne typy ich synchronizacji i komunikacji, obiekty chronione, semafory, wszystko to jest w Adzie wbudowane, bez używania zewnętrznych bibliotek. Na dodatek naprawdę łatwo jest z tego korzystać.
Potężnym narzędziem są też generics - odpowiednik szablonów C++. Umożliwiają tworzenie obiektów i funkcji, które są uogólnione pod względem użytych w nich typów zmiennych. Moim zdaniem ich tworzenie jest dużo łatwiejsze i bardziej czytelne niż używanie szablonów w C++.
W Adzie jest też postawiony duży nacisk na czytelność (choć jest to dość subiektywna sprawa). Składnia nie zawiera dziwnych operatorów typu & lub ^ lub ||, używane są zazwyczaj angielskie słowa.
Na koniec napiszę kilka wad, żeby nie było za słodko
. Silna typizacja czasami mocno denerwuje, niektórzy narzekają na zbyt dużą rozwlekłość składni. Niektore rzeczy można też uznać za nadmiarowe (np. konieczność zamykania definicji procedury jej nazwą).
Originally posted by elpako:
Co do samej Ady to ponoc nawet do wojskowych zastosowan byla polecana? Dobrze kojarze?
Zgadza się, co więcej, została stworzona przez Departament Obrony Narodowej USA na potrzeby wojska i lotnictwa. Dlatego głównym założeniem przy projektowaniu języka była niezawodność.
Originally posted by Big_Z:
Dla mnie, w tym konkretnym wypadku, językiem kompilowanym jest dowolny język, który można skompilować do kodu maszynowego AMD 64. Wszystkie pozostałe uważam za języki interpretowane.
Java, podobnie jak języki .Net, jest torchę problematyczna w tej klasyfikacji. To takie ogniwo pośrednie między językami interpretowanymi, a kompilowanymi. W każdym razie, jeśli założyć, że Java jest kompilowana do postaci kodu maszynowego, to interpretowany jest właśnie ów kod maszynowy, wirtualna maszyna to taki właśnie interpreter.
Java jest jezykiem interpretowanym i niezlomna wiara jej wielbicieli nie jest w stanie tego zmienic.
Podzial jest bardzo prosty. Albo mamy jedna "warstwe" czyli procesor->kod programu - jest to wtedy jezyk kompilowany, kod wynikowy
jest kodem maszynowym; albo mamy warstw wiecej, czyli procesor->interpreter->kod programu - jest to wtedy jezyk interpretowany.
Interpreter mozna sobie nazwac wirtualna maszyna, 'softwareowym rozszerzeniem procesora', albo magicznym kroliczkiem,
nie ma zadnej roznicy.
To ze tekst kodu moze zostac obrobiony do "bytecodeu", nie ma znaczenia. Moze to pozytywnie wplywac na szybkosc wykonywania
programow, ale nie jest to kompilacja w takim samy rozumieniu jak w przypadku np C.
Juz blizej pelnej kompilowalnosci od Javy jest Visual Basic P-Code, a zwykly VB jeszcze blizej - choc tez bym ich nie uznal za kompilowane.
Jeśli chodzi zaś o asembler, aż tak nisko nie zamierzam jeszcze iść. Poza tym język może być popularny, pisałem tylko, że nie musi.
Ja bym ci jednak asemblera polecal. Klasyczne C, bez obiektowych nalecialosci, jest juz dosc blisko procesora i jesli chcesz zobaczyc
widoczna roznice w tej 'bliskosci', to najlepszym wyborem bedzie asembler.
Nie wiem jak duzo wiesz o asemblerze, ale mozliwe ze niepotrzebnie sie tego jezyka boisz. Czasy kiedy trzeba bylo kombinowac
przy kazdym wypisaniu tekstu na ekran w asemblerze juz dawno minely. Teraz mamy pseudo-polecenia wysokiego poziomu,
bardzo latwy dostep do WinAPI i wyspecjalizowane srodowiska programistyczne dla asemblera.
Jakby co, to odezwij sie na priv.
Właściwie to moim głównym systemem operacyjnym jest Linux, więc chyba nie mam bezpośredniego dostępu do WinApi...
Programuje w asmie tylko pod winde, wiec wiekszosc moich linkow jest do tematow WinAsm,
ale przez rozne fora asmowe na pewno latwo ci bedzie trafic na materialy o linuxowym asemblerze.
Co moglem znalezc na szybko, prze wikipedie to
http://asm.sourceforge.net/
no i oczywiscie jeden z najlepszych istniejacych asemblerow FASM by Tomasz Grysztar chodzi pod Linuxem:
http://flatassembler.net/
Samo "jadro" jezyka jest oczywiscie identyczne pod win i lin, wiec pozostala kwestia jest tylko znalezienie
odpowiedniego srodowiska programistycznego i nauczenie sie odwolan do funkcji systemowych.
Originally posted by Big_Z:
Chodzi mi to stwierdzenie po głowie kilka dni i trochę mnie zirytowało. Czy żeby sensowanie brać udział w projekcie muszę wysyłać 5 patchów dziennie? To jest Twoja teoria? Czy nigdy w swoim ulubionym programie nie miałeś akurat kilku cech, które Cię irytowały? Może inni też mieli takie odczucia i będą Ci wdzięczni właśnie za tę 1 prostą poprawkę? Myślę, że gdyby odrzucać wszystkich mniej aktywnych developerów, projekty sporo cofnęłyby się w rozwoju. Może mam mało czasu, ale lubię raz w miesiącu usiąść do danego projektu i poprawić w nim coś, o czym inni nie pomyśleli (albo nie umieli tego wykonać) i przydać się tam na coś.Programista, który tylko sporadycznie wysyła swoje drobne rozszerzenia do projektu, nie jest wiele wart.
@MrL
Jak patrzę na asembler AMD64, dochodzę do dziwnego wniosku. To jest (prawie) bezużyteczny język. Gdyby było inaczej, procesory o nowocześniejszych zestawach rozkazów zdeklasowałyby IA-32.
@Zajec
Ja sobie nie mogę wymyśleć projektu, łatki, funkcjonalności, aby móc napisać w relatywnie krótkim czasie wartościowy fragment kodu. Może podałbyś jakiś konkretniejszy przykład?
Big_Z -> Bez urazy, ale przez ten cały czas dywagacji zdążyłbyś się już zapoznać z dokumentacją jakiegoś ciekawego projektu i zacząć COŚ robić .
Originally posted by Big_Z:
Jak patrzę na asembler AMD64, dochodzę do dziwnego wniosku. To jest (prawie) bezużyteczny język. Gdyby było inaczej, procesory o nowocześniejszych zestawach rozkazów zdeklasowałyby IA-32.
Nie bardzo rozumiem. W jakim sensie bezuzyteczny?
Ten paskudny tryb zgodności z poprzednimi procesorami. Te zalecenia stosowania dziwnych konstrukcji, aby uzyskać krótsze instrukcje. Niespójne nazwy rejestrów... Toć to normalnie masakra...
Gdyby programowanie w asemblerze przynosiło wymierne efekty, konkurencyjne procesory, które nie mają dziwnych naleciałości, byłyby popularniejsze w tej chwili od IA-32.
A tak, wszyscy programują chyba w językach wyższego poziomu i mają gdzieś, na jakich instrukcjach pracuje ich maszyna.
Originally posted by Big_Z:
Ten paskudny tryb zgodności z poprzednimi procesorami.
Bez tego trudno by bylo je wprowadzic na rynek. Dokladnie tak samo zrobiono przy przejsciu z 16 na 32 bity.
Zgodnosc wsteczna to bardzo dobra rzecz.
Te zalecenia stosowania dziwnych konstrukcji, aby uzyskać krótsze instrukcje.
To ich nie stosuj, tylko ucz sie jezyka. Dlugosc instrukcji nie zacznie cie interesowac jeszcze bardzo dlugo.
Niespójne nazwy rejestrów... Toć to normalnie masakra...
W jakim sensie niespojne?
Gdyby programowanie w asemblerze przynosiło wymierne efekty, konkurencyjne procesory, które nie mają dziwnych naleciałości, byłyby popularniejsze w tej chwili od IA-32.
"dziwnych nalecialosci"?
I co ma asembler do sukcesu rynkowego procesora, skoro pod wszystko mozna pisac w wyzszym poziomie, asemblera
w ogole nie widzac?
A tak, wszyscy programują chyba w językach wyższego poziomu i mają gdzieś, na jakich instrukcjach pracuje ich maszyna.
Maja tak dlugo gdzies, jak dlugo program sie ladnie przenosi. A nie zawsze dobrze sie skompiluje pod inny procesor,
nie mowiac o przenoszeniu skompilowanych binariow.
No i oczywiscie nie wszyscy, tylko wiekszosc, a popularnosc jezyka podobno cie nie interesuje.
Zgodność ze starymi standardami jest fajna pod warunkiem, że znasz stary standard. Potem zaś nowi muszą uczyć się elementów starego standardu oderwanych od kontekstu, aby móc cieszyć się z dobrodziejstw updatów do niego.
Mam takie podświadome ograniczenie, że jeśli w danej technologii coś można zrobić optymalniej, to tak trzeba to zrobić.
Nazwy rejestrów: RAX, RBP, R14... Trzeba się nauczyć, co te nazwy oznaczają, bo nie niosą same w sobie czytelnego opisu. To właśnie nazywam niespójnością nazewnictwa.
Przez dziwne naleciałości mam na myśli to, że rejestry nazywają się czytelnie, a nauczenie się na pamięć tego, do czego służą, trwa tyle, co jednokrotne przeczytanie specyfikacji.
No właśnie. Wszyscy piszą chyba w językach wyższego poziomu. Może faktycznie nie zawsze kod jest kompilowalny na wszystkim, ale zawsze ukryje się wiele niedociągnięć danej architektury. Jedynie bardzo nieliczni piszą w asemblerze. A skoro bardzo nieliczni to robią, to znaczy, że nie ma na to zapotrzebowania, a więc jest praktycznie bezużyteczne. Popularność jest mi obojętna, ale nie użyteczność.
Originally posted by Big_Z:
Zgodność ze starymi standardami jest fajna pod warunkiem, że znasz stary standard. Potem zaś nowi muszą uczyć się elementów starego standardu oderwanych od kontekstu, aby móc cieszyć się z dobrodziejstw updatów do niego.
W wypadku procesorow stary standard nie jest oderwany od kontekstu, tylko jest czescia skladowa nowego standardu.
Jest "baza" na ktorej dobudowane sa nowe elementy.
Sa dla takiego rozwiazania bardzo dobre powody:
- nowy procesor bedzie robil to co stary, niezaleznie od swoich nowych mozliwosci. Po co wiec wymyslac stare procedury na nowo,
skoro rozwiazanie juz mamy i dziala dobrze.
- programisci ktorzy juz znaja asemblera nie musza wszystkiego uczyc sie od poczatku, wystarczy ze doucza sie nowosci,
poczatkujacy i tak musza sie wszystkiego nauczyc
- update kompilatorow, dezasemblerow, edytorow, itd jest latwy
- stary kod uruchomi sie na nowym procesorze
To nie jest wiec jakies wstecznictwo - trzymanie sie umarlego 'starego standardu'. Po prostu nie ma najmniejszego sensu
wyrzucac tego co juz dobrze dziala. Jak umiesz chodzic, a potem postanawiasz nauczyc sie biegac, to nie wymyslasz chodzenia
od nowa, nie?
Mam takie podświadome ograniczenie, że jeśli w danej technologii coś można zrobić optymalniej, to tak trzeba to zrobić.
To zalezy jak sobie zdefiniujesz optymalnosc.
Nazwy rejestrów: RAX, RBP, R14... Trzeba się nauczyć, co te nazwy oznaczają, bo nie niosą same w sobie czytelnego opisu. To właśnie nazywam niespójnością nazewnictwa.
Owszem niosa.
AH - Accumulator High
AL - Accumulator Low
AX - Accumulator Register
EAX - Extended Accumulator Register
RAX - REX Accumulator Register
...
RBP - REX Base Register
...
R14 - Register #14
itd
Nazewnictwo jest tutaj bardzo spojne i jak najbardziej niesie ze soba tresc.
A nauczyc sie wielu nazw trzeba w kazdym jezyku.
Przez dziwne naleciałości mam na myśli to, że rejestry nazywają się czytelnie, a nauczenie się na pamięć tego, do czego służą, trwa tyle, co jednokrotne przeczytanie specyfikacji.
A jak potem bedziesz programowal z uzyciem tych dlugich opisowych nazw?
No właśnie. Wszyscy piszą chyba w językach wyższego poziomu. Może faktycznie nie zawsze kod jest kompilowalny na wszystkim, ale zawsze ukryje się wiele niedociągnięć danej architektury. Jedynie bardzo nieliczni piszą w asemblerze. A skoro bardzo nieliczni to robią, to znaczy, że nie ma na to zapotrzebowania, a więc jest praktycznie bezużyteczne. Popularność jest mi obojętna, ale nie użyteczność.
Powinienes chyba dokladniej sprecyzowac do czego jezyk ktorego szukasz ma ci sluzyc. Do szybkiego pisania malych programikow?
Do zarobkowania? Do zabawy? Do nauki/zabawy? Dlaczego koniecznie AMD64 (skoro wysoki poziom to i tak nie zobaczysz roznicy)?
Dlaczego nie interpretowany?
Uniwersalnego do tych wszystkich zadan nie znajdziesz.
Tak, nazwy rejestrów nie zostały wyssane z palca. Sęk w tym, że są to nazwy historyczne, które raczej nie korespondują z nowymi trybami procesora, które są dużo bardziej elastyczne na stosowanie rejestrów, niż za czasów i8086.
Samego języka szukam głównie do nauki/zabawy. Wielkich aplikacji nie mam na razie ochoty pisać. Prawdopodobnie jakieś programiki do eksperymentalnej obróbki obrazków. Może jakieś proste algorytmiki sztucznej inteligencji. Czemu koniecznie AMD64? Bo mam taki procesor, a jego architektura pozwala na 64-bitowe inty bez większej straty wydajności.
Jeśli chodzi o zarobkowanie, na razie mi w szkole wbijają C#. Od biedy powinno wystarczyć, aby zarobić na podłączenie do Internetu i pizzę. Poza tym obecnie programuję jeszcze w PHP i nawet mi za to płacą. Obecnie w użyciu jest tyle języków interpretowanych, że można być pewnym, że jakiegoś kolejnego będzie się trzeba nauczyć, nawet jakby człowiek tego unikał.
Originally posted by Big_Z:
Tak, nazwy rejestrów nie zostały wyssane z palca. Sęk w tym, że są to nazwy historyczne, które raczej nie korespondują z nowymi trybami procesora, które są dużo bardziej elastyczne na stosowanie rejestrów, niż za czasów i8086.
Wszystkie stare funkcje rejestrow nadal sa w uzyciu. AX nadal zbiera wyniki, CX nadal steruje petlami, SI i DI nadal wskazuja
zrodlo/cel, itd. Kod maszynowy tez nadal jest zoptymalizowany do dokladnie takiego wykorzystywania rejestrow. Te nazwy nie
sa historyczne, tylko nadal aktualne.
Zreszta nikt ci nie kaze tych nazw uzywac. Jak masz taka fantazje mozesz uzyc kilku makr i miec nazwy jakie chcesz.
Ale obawiam sie ze zadnych lepszych nie wymyslisz.
Czemu koniecznie AMD64? Bo mam taki procesor, a jego architektura pozwala na 64-bitowe inty bez większej straty wydajności.
Tylko do czego beda ci tak duze inty potrzebne?
W najgorszym razie tak duże inty są mi potrzebne do płaskiego zarządzania pamięcią operacyjną.
W C i C++ jest ten problem, że nie ma wyraźnego określenia, ile dany typ zajmuje bitów. W językach obiektowych i interpretowanych często nawet jest z tym gorzej. Z tego powodu nie nauczyłem się jeszcze dobierać wielkości integera do potrzeb. Może jak zacznę programować w czymś bardziej restrykcyjnym, nauczę się. Może wtedy znajdę zastosowanie dla tak dużych intów, aczkolwiek zgadzam się, że 32 bity są dostatecznie dużą liczbą w większości przypadków.
Originally posted by Big_Z:
A w najlepszym ?W najgorszym razie tak duże inty są mi potrzebne do płaskiego zarządzania pamięcią operacyjną.
Originally posted by Big_Z:
Nie ma, bo i nie zależy to tylko od języka, ale też od architektury komputera i systemu opercyjnego, pod którym bedzie pracował program. Zerknij sobie np. do "Język C. Szkoła programowania" S. Pratta.W C i C++ jest ten problem, że nie ma wyraźnego określenia, ile dany typ zajmuje bitów.
Miałeś kiedyś przez to problemy w napisaniu programu ?
Jaki jest sens skupiać się na tak wyszczególnionych cechach języka, skoro piszesz, że nie znasz żadnego aż tak dobrze ?
Może nigdy nie zwrócisz na to uwagi, a wszystkie(?) Twoje potrzeby zaspokoi Perl.
Originally posted by Big_Z:
W najgorszym razie tak duże inty są mi potrzebne do płaskiego zarządzania pamięcią operacyjną.
32 bity pozwalaja zaadresowac 4GB pamieci. Potrzebujesz wiecej?
W C i C++ jest ten problem, że nie ma wyraźnego określenia, ile dany typ zajmuje bitów.
W danym srodowisku jest to bardzo dokladnie okreslone.
Chyba ze ja programuje w jakims dziwnym C.
W językach obiektowych i interpretowanych często nawet jest z tym gorzej.
Jesli nie jest to dokladnie okreslone, to kompilator/interpreter sam sobie dobiera wielkosc i programista nie musi o tym myslec.
Originally posted by Vambeer:
Jaki jest sens skupiać się na tak wyszczególnionych cechach języka, skoro piszesz, że nie znasz żadnego aż tak dobrze ?
Może nigdy nie zwrócisz na to uwagi, a wszystkie(?) Twoje potrzeby zaspokoi Perl.
Perl jest swietny. Do operacji na tekscie i dostepu do www wrecz fantastyczny.
Tez bym go zaproponowal, albo Pythona, ale Big_Z nie chce interpretowanego.
W najlepszym razie będę mógł operować sobie na liczbach stałoprzecinkowych w miejsce obecnych zmiennoprzecinkowych, oraz wykonywać znacznie mniej obliczeń na liczbach stałoprzecinkowych.
Skoro nie ma potrzeby wyraźnego określenia, jak długi jest int, po co jest int, long int, short int, a czasami nawet long long int? Do tego właściwie dochodzi jeszcze char, ale to już mało istotne. Wiadomo, że owe typy mogą różnić się dokładnością, ale co po tej wiedzy, jeśli dokładność i tak nie jest znana?
Originally posted by Big_Z:
W najlepszym razie będę mógł operować sobie na liczbach stałoprzecinkowych w miejsce obecnych zmiennoprzecinkowych, oraz wykonywać znacznie mniej obliczeń na liczbach stałoprzecinkowych.
No dobrze, tylko po ci takie duze liczby?
Skoro nie ma potrzeby wyraźnego określenia, jak długi jest int, po co jest int, long int, short int, a czasami nawet long long int? Do tego właściwie dochodzi jeszcze char, ale to już mało istotne.
W danym srodowisku jest to dokladnie okreslone.
A potrzebne jest po to, zeby nie zajmowac niepotrzebnie pamieci, oraz zeby kompilator wiedzial jaki kod maszynowy ma generowac.
Dodatkowo operowanie liczbami o "dowolnej" wielkosci (jak np w Pythonie) wymaga stalej kontroli ich wielkosci, realokowania pamieci
jesli zaczna zajmowac za duzo miejsca, itd - to kosztuje duzo mocy obliczeniowej.
Wiadomo, że owe typy mogą różnić się dokładnością, ale co po tej wiedzy, jeśli dokładność i tak nie jest znana?
Nie roznia sie dokladnoscia, tylko zakresem i jest on w danym srodowisku znany. Zreszta miedzy srodowiskami te roznice
nie sa az takie duze. Short o ile wiem zawsze ma 2 bajty, char 1, itd.
1. Można sobie zrobić wektor. Potem zaś wykonywać na nim pewne zadania...
2. Można sobie zrobić ułamek stałoprzecinkowy.
Jeśli zaś chodzi o te typy liczbowe. Czemu na jednym środowisku int ma mieć 2 bajty, a na innym 4? Czemu na jednym środowisku long ma mieć 4 bajty, a na innym 8? Przecież to tylko komplikuje przenoszenie programów. W dodatku nie wiadomo, jakie maski stosować...
Originally posted by Big_Z:
1. Można sobie zrobić wektor. Potem zaś wykonywać na nim pewne zadania...
2. Można sobie zrobić ułamek stałoprzecinkowy.
Tak samo jak na 32 bitach, roznica jest tylko w pojemnosci. A do 64 bitowych liczb i tak masz juz long long int, albo qword.
Wieksze zreszta tez sa dostepne.
Z jakas biblioteka bignum mozesz miec liczby po kilka tysiecy bitow jesli chcesz, nie potrzeba do tego procesora 64b.
Jeśli zaś chodzi o te typy liczbowe. Czemu na jednym środowisku int ma mieć 2 bajty, a na innym 4? Czemu na jednym środowisku long ma mieć 4 bajty, a na innym 8? Przecież to tylko komplikuje przenoszenie programów. W dodatku nie wiadomo, jakie maski stosować...
Ograniczenia procesora i systemu operacyjnego.
Jesli stawiasz na przenosnosc to musisz to brac pod uwage, albo pisac tak zeby nie przekraczac nigdy minimalnych zakresow.
Jak dla mnie to niepotrzebne komplikowanie sobie zycia.
W sumie nawet na 4-bitowym procesorze można operować na bardzo dużych liczbach i bardzo dużej pamięci. Nie będzie to jednak dostatecznie wydajne.
Jeśli zaś chodzi o C, należy zapomnieć, że istnieje long, zapomnieć, że istnieje short, zapomnieć, że czasami istnieje long long. I zostać przy int. To będzie bowiem optymalnie dobrane do systemu operacyjnego i procesora. O nadużywanie pamięci operacyjnej i przekraczanie zakresów nie należy się obawiać.
Jeśli chodzi o języki skryptowe, nie trzeba ich ze świecą szukać. Na chwilę obecną mam zamiar nauczyć się trochę TCL. Perl jest trochę zbyt rozbudowany, a Python nie ma średników.
Originally posted by Big_Z:
Chyba dobrze byłoby tez zapomniec o bardziej rozbudowanych typach jak np. unie (nawet zbudowane z samych intów).Jeśli zaś chodzi o C, należy zapomnieć, że istnieje long, zapomnieć, że istnieje short, zapomnieć, że czasami istnieje long long. I zostać przy int. To będzie bowiem optymalnie dobrane do systemu operacyjnego i procesora. O nadużywanie pamięci operacyjnej i przekraczanie zakresów nie należy się obawiać.
Operować na samych wskaźnikach i gdzie tylko się da wciskać pola bitowe (chociaż kto wie, jak je sobie kompilator zinterpretuje).
Originally posted by Big_Z:
Także w moich oczach ta cecha dyskwalifikuje Pythona....a Python nie ma średników.
Originally posted by Big_Z:
W sumie nawet na 4-bitowym procesorze można operować na bardzo dużych liczbach i bardzo dużej pamięci. Nie będzie to jednak dostatecznie wydajne.
Jak potrzebujesz liczb 64 bitowych, to uzywasz - czy sam procesor chodzi na 64, 32 czy 16 bitach - zeby rozwiazac problem.
Jak nie potrzebujesz, to nie uzywasz, bo i po co.
Jeśli zaś chodzi o C, należy zapomnieć, że istnieje long, zapomnieć, że istnieje short, zapomnieć, że czasami istnieje long long. I zostać przy int. To będzie bowiem optymalnie dobrane do systemu operacyjnego i procesora. O nadużywanie pamięci operacyjnej i przekraczanie zakresów nie należy się obawiać.
Pod 64 bitowym procesorem akurat long long bylby tak samo szybki jak zwykly int. Podejrzewam ze shorty sa tak samo szybkie jak
inty, nie chce mi sie teraz sprawdzac.
To jest kwestia dobierania zasobow/metod do rozwiazywanych problemow, oraz pewnej elegancji programowania, polaczonej ze
zrozumieniem tego co sie robi - rzeczy dzisiaj niestety zanikajacych.
Jeśli chodzi o języki skryptowe, nie trzeba ich ze świecą szukać. Na chwilę obecną mam zamiar nauczyć się trochę TCL. Perl jest trochę zbyt rozbudowany
To uzywaj tylko podstawowych czesci. Bardziej egzotyczne rozwiazania i tak nie sa prawie przez nikogo uzywane.
Tak jest zreszta w wiekszosci jezykow - kto uzywa zlozonego dziedziczenia w C kiedy pisze program dla siebie? Nikt.
Ja po 10 latach zabawy z Asemblerem nie znam wielu bardziej egzotycznych polecen i nie widze potrzeby sie ich uczyc.
a Python nie ma średników.
Heheh. Bezsrednikowa, piekna w swej prostocie i sztywnosci skladnia to akurat jedna z najlepszych rzeczy w Pythonie.
Originally posted by Vambeer:
Chyba dobrze byłoby tez zapomniec o bardziej rozbudowanych typach jak np. unie (nawet zbudowane z samych intów).
Unie akurat nie zmniejszaja szybkosci wykonywania programu, a oszczedzaja miejsce. Zmienne w unii maja po prostu ten sam adres
w pamieci. Np dwie zmienne, int i short beda zajmowaly 6 bajtow, a ich unia tylko 4.
Operować na samych wskaźnikach i gdzie tylko się da wciskać pola bitowe (chociaż kto wie, jak je sobie kompilator zinterpretuje).
A to juz niestety nie jest takie proste, ani jesli chodzi o szybkosc, ani zuzycie pamieci. Porownania mogly by sie bardzo
roznic w zaleznosci od kodu programu i kompilatora.
Ja fatalenie się czuję, jeśli coś jest, a ja tego nie znam. Muszę się tego chociaż w minimalnym stopniu nauczyć, aby wiedzieć, co to jest. Nie muszę tego stosować, ale muszę w razie potrzeby szybko się owego stosowania nauczyć. Ponadtko, jak coś ma egzotyczne funkcje, przykłady i tutoriale zawierają zawsze te egzotyczne funkcje, więc robią się nieczytelne.
Średniki są potrzebne, jeśli coś ma być osadzone w kodzie innego języka. Zawsze wyglądają czytelniej i spójniej, niż encje dla znaku nowego wiersza.
Originally posted by Big_Z:
Ja fatalenie się czuję, jeśli coś jest, a ja tego nie znam. Muszę się tego chociaż w minimalnym stopniu nauczyć, aby wiedzieć, co to jest. Nie muszę tego stosować, ale muszę w razie potrzeby szybko się owego stosowania nauczyć.
Bardzo fajne podejscie. Byle tylko narzucic sobie jakies sensowne ograniczenia, bo przegladac absolutnie cala
dokumentacje jezyka nie ma sensu.
Ponadtko, jak coś ma egzotyczne funkcje, przykłady i tutoriale zawierają zawsze te egzotyczne funkcje, więc robią się nieczytelne.
Dobrze skonstruowana seria tutoriali powinna miec rosnacy stopien skomplikowania, w miare objasniania kolejnych
zagadnien.
A dobre przyklady, np uzycia konkretnych funkcji, powinny byc mozliwie jak najprostrze. Tak zeby do zrozumienia
pokazywanego zagadnienia potrzebna byla tylko minimalna znajomosc innych zagadnien.
Pewien zestaw funkcji oczywiscie jest w danym jezyku powszechnie uzywany i te funkcje przewijaja sie w wiekszosci
tekstow jakie o tym jezyku mozna znalezc. Ale tak jest ze wszystkimi jezykami i tego zestawu trzeba
sie po prostu nauczyc - to samo przychodzi po jakims czasie.
W przypadku bardziej rozbudowanych jezykow moze to byc troche uciazliwe, owszem.
Średniki są potrzebne, jeśli coś ma być osadzone w kodzie innego języka.
Hmm. Jak bedziesz osadzal jeden jezyk w innym?
Zawsze wyglądają czytelniej i spójniej, niż encje dla znaku nowego wiersza.
Zdania na ten temat sa oczywiscie podzielone, ale IMO skladnia Pythona jest o niebo lepsza od C, Javy i wielu innych.
Sredniki czasem sa na koncu linii, czasem nie, jest to niewyczerpane zrodlo bledow. Poza tym pozwalaja
umieszczac w jednej linijce wiecej niz jedna instrukcje(na szczescie malo kto z tego korzysta). Klamry mozna sobie
umieszczac gdzie sie chce i nie zawsze sa wymagane (jednopoleceniowy if). Wciecia sa zupelnie dowolne.
To wszystko obniza czytelnosc.
Dodatkowo srednik to dodatkowa rzecz do wklepania przy kazdym poleceniu, drobnostka ale zawsze.
Python pod wzgledem czytelnosci i spojnosci kodu jest swietny. Kazda instrukcja w osobnej linijce,
bloki oznaczane przez wciecia.
Wszystko pieknie widoczne. Nie ma zadnej dowolnosci, wiec albo piszesz czytelnie, albo wcale.
Jakbym chciał zrobić program w C, który wykonuje skrypty Pythona... Znaki końca lini są jeszcze akceptowalne, ale robienie bloków przez umieszczanie określonej liczby encji białych znaków albo samych białych znaków... Nie nazwałbym tego czytelnym.
Jako samodzielny język Python sprawdza się bardzo dobrze. Faktycznie jego składnia jest wtedy czytelna.
Przy okazji znalazłem informacje, ile dany typ ma w C bitów:
char 8+
short 16+
int 16+
long 32+
long long 64+
Wszystkie mogą być teoretycznie 64 bitowe, a nawet dłuższe.
Originally posted by Big_Z:
Jakbym chciał zrobić program w C, który wykonuje skrypty Pythona... Znaki końca lini są jeszcze akceptowalne, ale robienie bloków przez umieszczanie określonej liczby encji białych znaków albo samych białych znaków... Nie nazwałbym tego czytelnym.
Skoro mieszasz ze soba dwa jezyki, to trudno zeby ich wyglad byl podobny. Chociaz mozna oczywiscie sobie tak zalozyc, co kto lubi.
Przy okazji znalazłem informacje, ile dany typ ma w C bitów:
char 8+
short 16+
int 16+
long 32+
long long 64+
Wszystkie mogą być teoretycznie 64 bitowe, a nawet dłuższe.
Tak moze byc, ale nie musi. Dla przykladu, pierwsza specyfikacja jaka trafilem w google, IBM Mac OS X C++ podaje
ze int ma 32 bity.
Na procesorze 16bitowym (raczej) long mialby 16, a long long 32 bity.
Ot, trzeba sprawdzic jak ma sie u siebie i sie nie przejmowac.
W C jeśli chcemy operować na zmiennej o określonej liczbie bitów najlepiej korzystać z typów zdefinowanych w standardowym nagłówku stdint.h: int8_t, int16_t, int32_t, int64_t. Wtedy mamy pewność, że niezależnie od platformy wielkość zmiennej jest zawsze taka sama.
Na wszystkich platformach dolne limity dla intów są takie same. W pliku stdint.h jest kilka typów więcej: są jeszcze szybkie typy i małe typy, które mają gwarancję, że mogą operować na dostatecznie dużych liczbach. W każdym razie zrobiłem sobie programik, który wyświetlił, ile dany typ potrzebuje bitów. Sprawdziłem na Linuksie AMD 64 i GCC.
Jeśli ktoś potrzebuje 32 bitów, ma do wyboru:
long - który mu wygeneruje 64 bity
int_fast32_t - który mu wygeneruje 64 bity
int_least32_t - który mu wygeneruje 32 bity
Całkiem logicznie. Aby nie męczyć się z ciągłą konwersją typów
Jeśli ktoś potrzebuje 16 bitów, ma do wyboru:
short - który mu wygeneruje 16 bitów
int - który mu wygeneruje 32 bity
int_fast16_t, który mu wygeneruje 64 bity
int_least16_t, który mu wygeneruje 16 bitów
Teraz zagadka, czemu jest tutaj generowana zmienna 32 bitowa? Nie chodzi tutaj o wydajność, bo zmienne fast dla 32 bitów i 16 bitów są równe 64 bitom. Nie chodzi też o oszczędność pamięci, bo w te miejsce stosuje się właśnie minimalne 16 bitów. Dziwne...
Jeśli chodzi o języki programowania nie jestem zaawansowany (a konkretnie jestem w połowie Wimmerowego kursu html ), ale znalazłem ciekawostkę.
Kod programu 99 Bottles of Beer napisany w 1227 różnych językach. Można przejrzeć pozycje, które wchodzą w grę przy wyborze.
Fajna strona, czasami można się pośmiać. Większość przykładadów jest jednak daleka od praktyczności i czytelności.
Do tych butelek osobiście chyba bym napisał w Tcl (dla wprawy) albo PHP (z doświadczenia). Do zabawy stringami raczej wybiera się języki interpretowane, które nie mają ścisłego podziału na liczby i stringi. Większa czytelność kodu.