-
51. Data: 2014-02-25 15:40:27
Temat: Re: Mlody Technik
Od: A.L. <a...@a...com>
On Tue, 25 Feb 2014 09:05:28 +0100, sundayman
<s...@p...onet.pl> wrote:
>
>> Z samplow to mam moje najwieksze dzielo literackie: ksiazke
>> Programowanie Milkrokomputerow w Jezyku Basic. Wydana pzrez Sigme.
>> Taka czerwona okladka. Wczesne lata 80
>
>pewnie to ?
>http://allegro.pl/frelek-mikrokomputer-programowani
e-w-jezyku-basic-i4000600568.html
>
Dokladnie to. Frelek to nei ja, to moj wspolautor
Ciekawe ze ludzie jeszcze tym handluja...
>No jak raz nie miałem niestety, ale pamiętam okładkę skądś - to był
>czas, że literatury było jak na lekarstwo :)
>
>Ale mam właśnie w ręku inną z tej serii;
>http://allegro.pl/rydzewski-sacha-mikrokomputer-ele
menty-budowa-dzia-i3936802214.html
>
ta sama mafia :)
A.L.
-
52. Data: 2014-02-25 16:05:49
Temat: Re: Mlody Technik
Od: Sylwester Łazar <i...@a...pl>
> No dobra, ale teraz miej 10K takich instrukcji i zrob optymalizacje
> ercznie
>
> A.L.
Zauważ proszę, że takie myślenie jest podobne do niekontrolowanej reakcji
atomowej.
Jeżeli wyciągniemy pręty, jak w Czernobylu, zaraz się okaże, że co drugi kod
potrzebuje 1TB dysku.
Taka optymalizacja mechaniczna jest protezą, źle napisanego kodu.
Studiowanie MIPSów i tych chorych DELAY slots, zmuszała mnie do
przestawiania instrukcji, czy funkcji
na poziomie, nie mechanicznym, a logicznym.
Czuło się tak, jakby dwie procedury należało nałożyć na siebie jak firanka z
zasłonką,
aby wykonywały się równocześnie.
Żaden kompilator tego nie zrobi lepiej. Może najwyżej poprawić coś, co się
przeoczyło.
Jednak zgadzam się z tym, że te sloty to niepotrzebne utrudnienie.
Gdzieś wyczytałem, że w starych rozwiązaniach był jeszcze problem DELAY
slotów.
Jednak zwalanie całej roboty na kompilator i ufanie w jego nadzwyczajne
możliwości, jest
też na wyrost.
Toż przecież jeśli programista nie podglądnie jak będzie wyglądał jego kod
po skompilowaniu,
to zadowala się tym co jest, jeśli jakoś tam działa. Długość kodu w ogóle go
nie interesuje.
Jeśli nie starczy - wybierają większy chip.
A program ma regulację dwupołożeniową zrobić :-)
Jeżeli przyjrzysz się temu co wyprawia kompilator w środowisku MPLABa, to
zauważysz,
jak odkłada na stos wszystkie rejestry (tak na wszelki wypadek pewnie :-)),
a potem robi "r5++" i następnie ściąga z mozołem tobołki ze stosu.
A to tylko dlatego, że jest procedura obsługi przerwania i tak przyjęli
twórcy kompilatora.
Piszę też w C. Jednak do aplikacji działających w okolicy ~Tcy, kompilator
psuje możliwości
kontrolera. Wtedy trzeba brać większą kostkę i lepszy kompilator.
Potem już tylko Windows i robią się te 10k kody.
To zdecydowanie nie moja działka.
Ja lubuję się w zwartych i szybkich rozwiązaniach i przekroczenie 2k kodu to
rzadkość.
Zostawiam pole 10k dla innych :-)
S.
-
53. Data: 2014-02-25 16:45:02
Temat: Re: Mlody Technik
Od: "J.F" <j...@p...onet.pl>
Użytkownik "Sylwester Łazar" napisał w wiadomości
>> Tylko przyjemne to nie jest, i jak piszesz - na niektorych program
>> chodzi, na innych nie chodzi, na innych chodzi gorzej - i nie
>> wystarczy przestawic opcji w kompilatorze.
>Ludzie sudoku godzinami rozwiązują, a Ty piszesz, że to nieprzyjemne
>:-)
Sudoku moze i jest przyjemne (dla mnie przestalo jak zobaczylem
program rozwiazujacy), ale to to nie.
Pulapka w kazdej instrukcji.
Chwale procesory, gdzie w assemblerze pisze sie prawie tak samo szybko
jak w C.
> > Dla przykladu - problem z dzisiejszego egzaminu :)
> > Problem 7 - 15 points. Given is the following fragment of a
> > program
> > executed by a pipeline
> > add $s0, $s0, $t1
> > lw $t2, 20($t1)
> > and $t4, $t2, $t5
> > or $t8, $t2, $t6
> > add $t9, $t4, $t2
> > slt $t1, $t6, $t7
>> Nie powinno byc to zalatwione sprzetowo - procesor sam wstawia nop
>> zanim dane nie beda osiagalne ? Oczywiscie nadal kompilator moze
>> optymalizowac.
>Jeżeli kompilator miałby wstawiać nopy, to jest to najgorsze
>rozwiązanie,
>ale za to bardzo proste.
Ale ja postuluje zeby to robil procesor ... w miare potrzeby.
Tak swoja droga to duze brawa dla konstruktorow z Intela, ze udalo im
sie to wszystko i wiecej w procesor upchnac.
J.
-
54. Data: 2014-02-25 17:14:39
Temat: Re: Mlody Technik
Od: Sylwester Łazar <i...@a...pl>
> >Jeżeli kompilator miałby wstawiać nopy, to jest to najgorsze
> >rozwiązanie,
> >ale za to bardzo proste.
>
> Ale ja postuluje zeby to robil procesor ... w miare potrzeby.
No to się nie da, bo jest taki jak go fabryka wyprodukowała.
Kompilator ma zawsze 6 etapów rozwoju:
1) zamienić HIGH Level na asm byle by jakoś działało.
i wtedy przynosi dla piszącego krocie:
a) na sprzedaży urządzenia
b) na serwisie oprogramowania
2) Wprowadzić optymalizację kodu poprzez wstawianie NOPów.
To się marketingowo sprzedaje, porównując do 3 innych z punktu 1)
3) Wprowadzić optymalizację kodu, który przestawia instrukcje.
Nazwać go jakimś słowem: ULTRA, LUX czy podobnie.
Cena x4 i dużo reklamy. Piszący ciągle nie zauważa różnicy
4) Wprowadzić 100 checkboxów, aby każdy mógł sobie sam zrobić kompilator
jaki potrzebuje.
Wtedy ludzie się wymieniają informacjami, jak najlepiej poustawiać silnik,
aby zapalił. Za niektóre złote checkboxy trzeba dopłacić.
Cena kompilatora x10. Programista ma już 1/4 głowy siwych włosów.
5)SUPER, CROSS, MULTI FUNCTIONAL, 5 GENERATION COMPILER
Ten już ma wszystko. Cena x20, kupują już go nieliczni, kod po kompilacji
jest tylko 5x dłuższy niż tego z pkt.1)
6) WEB Kompilator .
Aplikacja wysyła kod źródłowy na serwer. Tam 1000 programistów z całego
świata, ręcznie, kompilują fragmenty. Wygrywa najszybszy kod i taki wraca do
użytkownika.
Użytkownik oczywiście w niczym się nie orientuje, bo trwa to 5 minut i w tym
czasie na ekranie lecą mu różne losowo
wybrane komunikaty, których nikt na świecie jeszcze nie czytał on-line.
:-)
S.
-
55. Data: 2014-02-25 17:15:47
Temat: Re: Mlody Technik
Od: Sebastian Biały <h...@p...onet.pl>
On 2014-02-24 15:50, Marek wrote:
> W asm? Jeśli tak to Sylwek się ucieszy bo pic32 to mips ;)
Jedna z ciekawszych pozycji o asm jakie miałem okazję czytać tez bazuje
*właśnie* na MIPS:
http://en.wikipedia.org/wiki/Hacker's_Delight
-
56. Data: 2014-02-25 17:43:46
Temat: Re: Mlody Technik
Od: Sylwester Łazar <i...@a...pl>
> > W asm? Jeśli tak to Sylwek się ucieszy bo pic32 to mips ;)
>
> Jedna z ciekawszych pozycji o asm jakie miałem okazję czytać tez bazuje
> *właśnie* na MIPS:
>
> http://en.wikipedia.org/wiki/Hacker's_Delight
Teraz już nie ma hackerów. Jest Facebook.
S.
-
57. Data: 2014-02-25 18:46:22
Temat: Re: Mlody Technik
Od: sundayman <s...@p...onet.pl>
> W takim razie Panie Andrzeju, skladam gorace podziekowania za wlozona prace.
> Bardzo dziekuje w imieniu tych, co sie uczyli na Pana materialach i
> korzystali
> z ogromnej wiedzy.
Popieram ! :)
> No prosze, jakich wybitnych naukowców mozna znalezc na p.m.e. !
ano, szczęśliwie na usenecie można jeszcze trafić na parę wartościowych
osób oprócz dzieci neostrady.
-
58. Data: 2014-02-25 19:48:19
Temat: Re: Mlody Technik
Od: Przemek <r...@o...pl>
> Jeszcze potem był taki na ULN1321 zdaje się.
Dokładnie :)
Tego ja robiłem, niestety 500km od Wawy słabo działał, ale inne stacje
ściągał :)
Przem
-
59. Data: 2014-02-25 19:59:10
Temat: Re: Mlody Technik
Od: Przemek <r...@o...pl>
> Hehe, też gdzieś to powinienem mieć. :-) I drugą część/kontynuację
> również, ponieważ, AFAIR, wyszło coś takiego.
Do tego "Elektronika łatwiejsza niż przypuszczasz" w czterech tomach i
"Radioelektronika dla praktyków"...
Oj robi się zbowidowo :)
Przem
-
60. Data: 2014-02-25 21:28:11
Temat: Re: Mlody Technik
Od: Sylwester Łazar <i...@a...pl>
Użytkownik Przemek <r...@o...pl> w wiadomości do grup dyskusyjnych
napisał:leioiu$j3q$...@n...news.atman.pl...
> > Jeszcze potem był taki na ULN1321 zdaje się.
>
> Dokładnie :)
> Tego ja robiłem, niestety 500km od Wawy słabo działał, ale inne stacje
> ściągał :)
> Przem
O kurcze! powinno być UL1321N. Przepraszam.
Ja to nawet nie pamiętam, jak odbierał w Poznaniu, ale chyba dobrze, bo
wspomnienia są miłe.
S.