🚀 go-pugleaf

On Fri, 19 Oct 2007 15:36:07 +0200, Remek wrote:

> Witam
> 
> Czy ta grupa jeszcze żyje?
> 
> Pozdrawiam  Remek

jak widac niezbyt, teraz jedyne assembly jakie ludzie uprawiaja to te w 
.NET :)

-- 
Bartosz Wójcik | www.pelock.com

Remek pisze:
> Witam
> 
> Czy ta grupa jeszcze żyje?

 Jak ktoś ma pytanie, to dostaje odpowiedź, więc chyba żyje. Nie ma tu
dyskusji, który kompilator/system jest lepszy (i dobrze!). A jak nie
ma o czym dyskutować (lub pomysły w rozwiązywaniu problemów się
skończyły), to nikt nie pisze. Masz pytanie? Zadaj je. Masz problem i
nikt nie potrafi pomóc? Wykonaj własne badania lub pokaż więcej
szczegółów (jak na przykład z problemem z HLA).

-- 
Pozdrawiam/Regards - Bogdan                         (Linux & FreeDOS)
Kurs asemblera x86  (DOS & Linux):  http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Rozmawiaj bezpiecznie: www.JabberPL.org Surfuj anonimowo: tor.eff.org

Remek wrote:
> Czy ta grupa jeszcze żyje?

Jak widać nie za bardzo.  Pewnie przez to, że nikt nie używa asemblera
(bo i po co?).

w.

Wojciech Muła pisze:
> Remek wrote:
>> Czy ta grupa jeszcze żyje?
> 
> Jak widać nie za bardzo.  Pewnie przez to, że nikt nie używa asemblera
> (bo i po co?).

 Asembler jest jak najbardziej używany (bootsektory, jądra,
sterowniki, systemy wbudowane, programy multimedialne). Tyle, że mało
o tym słychać. Języki wyższych poziomów pozwalają na szybszy rozwój
aplikacji i są bardziej przenośne, dlatego są częściej używane.
 Na grupie jest cisza, bo nikt nie zadaje pytań i wszyscy zajęli się
swoimi sprawami :)

-- 
Pozdrawiam/Regards - Bogdan                         (Linux & FreeDOS)
Kurs asemblera x86  (DOS & Linux):  http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Rozmawiaj bezpiecznie: www.JabberPL.org Surfuj anonimowo: tor.eff.org

Użytkownik "Wojciech Muła" napisał:

> Jak widać nie za bardzo. Pewnie przez to, że nikt nie używa asemblera
> (bo i po co?).

W takim razie zapewne nie używa również debuggera, bo bez podstawowej
choćby znajomości asm'a niczego nie zrozumie :)

Pozdrawiam  Remek

Bogdan (bogdro) wrote:

>> Jak widać nie za bardzo.  Pewnie przez to, że nikt nie używa asemblera
>> (bo i po co?).
> 
>  Asembler jest jak najbardziej używany (bootsektory, jądra,
> sterowniki, systemy wbudowane, programy multimedialne). Tyle, że mało
> o tym słychać.

Malo o tym slychac bo i malo tam assemblera ;) Juz nawet na
mikrokontrolerach c++ zaczyna przewazac.

Stety i niestety zarazem...

-- 
Michal Schulz

Remek wrote:
> Użytkownik "Wojciech Muła" napisał:
> 
>> Jak widać nie za bardzo. Pewnie przez to, że nikt nie używa asemblera
>> (bo i po co?).
> 
> W takim razie zapewne nie używa również debuggera, bo bez podstawowej
> choćby znajomości asm'a niczego nie zrozumie :)

Zależy, co debugujesz. Mi przy debugowaniu jeszcze nigdy znajomość 
asemblera nie była potrzebna - to i moja jego znajomość jest mierna 
przez beznadziejna.

JD

>  Asembler jest jak najbardziej używany (bootsektory, jądra,

Po prostu asemblerem zajmują się profesjonaliści, a oni o nic nie
muszą pytać.

Użytkownik "Geo" napisał:

> Po prostu asemblerem zajmują się profesjonaliści, a oni o nic nie
> muszą pytać.

Po prostu urodzili się profesjonalistami i wszelką wiedzę wyssali z
mlekiem matki. Potrafią wszystko, z nikim nie muszę się dzielić wiedzą i
niczego nowego nie odkrywają, bo to niemożliwe.

Remek

> Po prostu urodzili się profesjonalistami i wszelką wiedzę wyssali z
> mlekiem matki. Potrafią wszystko, z nikim nie muszę się dzielić wiedzą i
> niczego nowego nie odkrywają, bo to niemożliwe.


Dokładnie tak, a pytania zadają tylko lamerzy, ktorzy teraz trenują
HLL - zobacz na tamte grupy, jest DUŻO pytań.

Użytkownik "Geo" napisał:

> Dokładnie tak, a pytania zadają tylko lamerzy, ktorzy teraz trenują
> HLL - zobacz na tamte grupy, jest DUŻO pytań.

Dokładnie tak? Tzn. urodzili się z wiedzą, a pytania zadaja tylko
lamerzy? Nie wiem co robisz na tej grupie, bo do niej nie pasujesz. Słoma
Ci wyłazi z butów, a próbujesz się mądrować.

> zobacz na tamte grupy

Co to ma być? Chodziłeś do podstawówki? Nie potrafisz sklecić poprawnego
zdania po polsku. Jeśli dobrze kojarzę nick, to udzielasz się nie tylko
na tej grupie, wywołując awantury swoimi bezczelnymi i debilnymi postami.

Sio! KF!

Remek

Ty ty robisz tutaj awantury swoimi glupimi postami i to tobie wylazi
słoma z butów. Ja z toba świń nie pasłem, więc odpierd... się od mojej
osoby. Debilem też jesteś TY (to tak na marginesie).

Wojciech Muła napisał(a):
> Remek wrote:
> > Czy ta grupa jeszcze żyje?
>
> Jak widać nie za bardzo.  Pewnie przez to, że nikt nie używa asemblera
> (bo i po co?).
Jak nikt ... :| ja używam, to piękny i wspaniały język...

Pozdrawiam

> Jak nikt ... :| ja używam, to piękny i wspaniały język...

I do tego jedyny prawdziwy

Pozdrawiam

On 29 Paź, 10:14, Michal Schulz <michal.sch...@onet.eu> wrote:
> Geo wrote:
> >> Jak nikt ... :| ja używam, to piękny i wspaniały język...
>
> > I do tego jedyny prawdziwy
>
> Jaki tam prawdziwy. Nowe procesory i tak interpretuja mikroinstrukcje :P
>
> --
> Michal Schulz

A od kiedy programujesz procesor Pentium, Motorole, czy inny
mikrokodem? Jeśli tak, klaniam sie nisko.

Geo wrote:

>> > I do tego jedyny prawdziwy
>>
>> Jaki tam prawdziwy. Nowe procesory i tak interpretuja mikroinstrukcje :P
> 
> A od kiedy programujesz procesor Pentium, Motorole, czy inny
> mikrokodem? Jeśli tak, klaniam sie nisko.

Nie programuje. Ale nie przekonasz mnie ze to jedyny prawdziwy jezyk
procesora ;)

-- 
Michal Schulz

Geo wrote:

>> Jak nikt ... :| ja używam, to piękny i wspaniały język...
> 
> I do tego jedyny prawdziwy

Jaki tam prawdziwy. Nowe procesory i tak interpretuja mikroinstrukcje :P

-- 
Michal Schulz

On 29 Paź, 09:54, Michal Schulz <michal.sch...@onet.eu> wrote:
> Nie programuje. Ale nie przekonasz mnie ze to jedyny prawdziwy jezyk
> procesora ;)

Czemu miałbym kogokolwiek do czegokolwiek przekonywać. Masz swoje
zdanie. OK. Ja mam swoje. Zważ tylko na to, iż mikrokod jest istotny
dla projektantów procesora, a nie dla programistów - wszystkie języki
HLL sprowadzane są przez kompilatory do asemblera, a nie do mikrokodu.
Zatem asembler lezy u podstaw programowania i już. A jeśli w
prezyszłości powstaną procesory bez mikrokodu jako takiego (jakies
super RISC)?

Pozdrawiam

Użytkownik "Michal Schulz" napisał:

> Jaki tam prawdziwy. Nowe procesory i tak interpretuja mikroinstrukcje
:P

Makroinstrukcje jakiego języka? Asembler jest językiem programowania
niskiego poziomu obsługującym instrukcje danego procesora. Inaczej
mówiąc: ile procesorów, tyle asemblerów. Nie ma jednego uniwersalnego do
wszystkich rodzajów procesorów. Jeśli nowy procesor oferuje nowe
instrukcje, musi za nim pójść aktualizacja asemblera, lub stworzenie
nowego w zależności jaki jest stopień kompatybilności "w dół". Nie ma co
do tego mieszać języków wysokiego poziomu oferujących gotowe rozwiązania.


Remek

Remek wrote:
> Użytkownik "Michal Schulz" napisał:
> 
>> Jaki tam prawdziwy. Nowe procesory i tak interpretuja mikroinstrukcje
> :P
> 
> Makroinstrukcje jakiego języka?

Ale mowa była o mikroinstrukcjach.

> Jeśli nowy procesor oferuje nowe
> instrukcje, musi za nim pójść aktualizacja asemblera,

Ale może oferować nowy zestaw mikroinstrukcji, bez nowych instrukcji. 
Wtedy nic nie musi być zmieniane.

JD

Użytkownik "Jedrzej Dudkiewicz" napisał:

> > Makroinstrukcje jakiego języka?

> Ale mowa była o mikroinstrukcjach.

Faktycznie. Z rozpędu napisałem mało logicznie.

> > Jeśli nowy procesor oferuje nowe
> > instrukcje, musi za nim pójść aktualizacja asemblera,

> Ale może oferować nowy zestaw mikroinstrukcji, bez nowych instrukcji.
> Wtedy nic nie musi być zmieniane.

Chodzi o to, że te makroinstrukcje oferowane/obsługiwane przez dany
procesor muszą być zaimplementowane do danego języka programowania. W
przeciwnym razie nie będą mogły być przetłumaczone na język maszynowy, bo
asembler/kompilator ich nie zrozumie.

Remek

Remek pisze:
>> Ale może oferować nowy zestaw mikroinstrukcji, bez nowych instrukcji.
>> Wtedy nic nie musi być zmieniane.
> 
> Chodzi o to, że te makroinstrukcje

 Mikro, mikro, mikro...

> oferowane/obsługiwane przez dany
> procesor muszą być zaimplementowane do danego języka programowania. W
> przeciwnym razie nie będą mogły być przetłumaczone na język maszynowy, bo
> asembler/kompilator ich nie zrozumie.

 To nie jest tak, że mikroinstrukcja to takie coś, jak instrukcja.
Nowoczesne procesory "rozbijają" złożone operacje, jak np. IMUL na
zestaw mniejszych "podzadań". Zestaw tych podzadań zwany jest
mikrokodem i jest niewidoczny dla nikogo. Asemblery i inne kompilatory
dalej produkują instrukcję IMUL, ale procesor inaczej ją przetwarza.
 To też przypomina działanie procesorów Transmety - z zewnątrz
programowalne jak x86, wewnątrz - własna architektura.
 Nie da się, według mojej wiedzy, programować bezpośrednio w
mikro-opach. Najniższy możliwy poziom to ręczna zmiana napięć w
komórkach pamięci, tworząc różne stany napięć ("bity"), składające się
na instrukcje ;)

-- 
Pozdrawiam/Regards - Bogdan                         (Linux & FreeDOS)
Kurs asemblera x86  (DOS & Linux):  http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Rozmawiaj bezpiecznie: www.JabberPL.org Surfuj anonimowo: tor.eff.org

Użytkownik "Bogdan (bogdro)" napisał:

> > Chodzi o to, że te makroinstrukcje

>  Mikro, mikro, mikro...

Sorry!!! Zaćmienie.


Remek

Bogdan (bogdro) wrote:

> 
>  To nie jest tak, że mikroinstrukcja to takie coś, jak instrukcja.
> Nowoczesne procesory "rozbijają" złożone operacje, jak np. IMUL na
> zestaw mniejszych "podzadań". Zestaw tych podzadań zwany jest
> mikrokodem i jest niewidoczny dla nikogo. Asemblery i inne kompilatory
> dalej produkują instrukcję IMUL, ale procesor inaczej ją przetwarza.
>  To też przypomina działanie procesorów Transmety - z zewnątrz
> programowalne jak x86, wewnątrz - własna architektura.
>  Nie da się, według mojej wiedzy, programować bezpośrednio w
> mikro-opach. Najniższy możliwy poziom to ręczna zmiana napięć w
> komórkach pamięci, tworząc różne stany napięć ("bity"), składające się
> na instrukcje ;)

a nie tyczy to nawet starych procków i mikrokontrolerów ?
własnie na studiach mam przedmiot traktujący o budowie powyższych i tam
to się pojawia nawet w najstarszych układach.
w koncu nawet starce procki musiały wiedzieć skąd dokąd i w jakiej
kolejnosci skopiować/dodać/przetworzyć itd żeby do ramu trafił wynik
2+2 ;)

co do możliwosci kodowanie w mikrorozkazach - masz rację, jeśli wierzyc
mojemu wykładowcy;) to mikroprogramy siedza w romie wbudowanym w procek
i nie ma siły zeby je zmienić

-- 
Michał Walenciak,   gg: 3729519,  mail: Kicer86 na gmail kropka com
http://kicer.elsat.net.pl

Kicer wrote:
> co do możliwosci kodowanie w mikrorozkazach - masz rację, jeśli wierzyc
> mojemu wykładowcy;) to mikroprogramy siedza w romie wbudowanym w procek
> i nie ma siły zeby je zmienić

Na wszelki wypadek radzę nie wierzyć wykładowcom.

W procesorach Intela część kodów można zmienić (są ważne do
następnego restartu), na wypadek bugów; ostatnie procesory Core
mają kilkadziesiąt znanych błędów.  Niestety, producent nie
udostępnia specyfikacji, jedynie dostarcza patche i zdefiniowany
jest sposób wgrania łatki.

w.

Wojciech Muła napisał(a):
> Kicer wrote:
> > co do możliwosci kodowanie w mikrorozkazach - masz rację, jeśli wierzyc
> > mojemu wykładowcy;) to mikroprogramy siedza w romie wbudowanym w procek
> > i nie ma siły zeby je zmienić
>
> Na wszelki wypadek radzę nie wierzyć wykładowcom.
Amen. Słowa święte i powinny zostać wpisane do dekalogu jako pierwsze
przykazanie (każdego dekalogu :P)

Pozdrawiam

Kicer pisze:
> Bogdan (bogdro) wrote:
> 
>>  To nie jest tak, że mikroinstrukcja to takie coś, jak instrukcja.
>> Nowoczesne procesory "rozbijają" złożone operacje, jak np. IMUL na
>> zestaw mniejszych "podzadań". Zestaw tych podzadań zwany jest
>> mikrokodem i jest niewidoczny dla nikogo. Asemblery i inne kompilatory
>> dalej produkują instrukcję IMUL, ale procesor inaczej ją przetwarza.
>>  To też przypomina działanie procesorów Transmety - z zewnątrz
>> programowalne jak x86, wewnątrz - własna architektura.
>>  Nie da się, według mojej wiedzy, programować bezpośrednio w
>> mikro-opach. Najniższy możliwy poziom to ręczna zmiana napięć w
>> komórkach pamięci, tworząc różne stany napięć ("bity"), składające się
>> na instrukcje ;)
> 
> a nie tyczy to nawet starych procków i mikrokontrolerów ?
> własnie na studiach mam przedmiot traktujący o budowie powyższych i tam
> to się pojawia nawet w najstarszych układach.
> w koncu nawet starce procki musiały wiedzieć skąd dokąd i w jakiej
> kolejnosci skopiować/dodać/przetworzyć itd żeby do ramu trafił wynik
> 2+2 ;)

 No tak, ale nie było to chyba tak przeprowadzane, jak podobno jest
teraz. Układ dodający można bodajże w jakiś nietrudny sposób zbudować
z bramek logicznych (ale szczegółów nie pamiętam). Bardziej złożone
operacje też pewnie były zakodowane jako jakieś własne "ścieżki
wykonywania". Teraz wygląda na to, że bardziej złożone operacje
rozkładane są na serie prostszych, których wyniki są odpowiednio łączone.

> co do możliwosci kodowanie w mikrorozkazach - masz rację, jeśli wierzyc
> mojemu wykładowcy;) to mikroprogramy siedza w romie wbudowanym w procek
> i nie ma siły zeby je zmienić

 Tego to nie wiem. Kolega Wojciech Muła napisał, że część mikrokodu da
sie zmienić. Wiedząc, że w jądrze Linuksa można włączyć opcje
aktualizacji mikrokodu (jeśli procek obsługuje, rzecz jasna), jestem
skłonny zgodzić się z tą opinią. Dotyczy to pewnie jednak tylko tych
złożonych operacji, dla których ma w ogóle sens pisanie mikrokodu.
Takiego algorytmu dodawania pewnie nie da się zmienić. Poprzestawiać
tranzystorków pewnie też się nie da :)

-- 
Pozdrawiam/Regards - Bogdan                         (Linux & FreeDOS)
Kurs asemblera x86  (DOS & Linux):  http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Rozmawiaj bezpiecznie: www.JabberPL.org Surfuj anonimowo: tor.eff.org

Bogdan (bogdro) wrote:
>  To nie jest tak, że mikroinstrukcja to takie coś, jak instrukcja.
> Nowoczesne procesory "rozbijają" złożone operacje, jak np. IMUL na
> zestaw mniejszych "podzadań". Zestaw tych podzadań zwany jest
> mikrokodem i jest niewidoczny dla nikogo. Asemblery i inne kompilatory
> dalej produkują instrukcję IMUL, ale procesor inaczej ją przetwarza.
>  To też przypomina działanie procesorów Transmety - z zewnątrz
> programowalne jak x86, wewnątrz - własna architektura.
>  Nie da się, według mojej wiedzy, programować bezpośrednio w
> mikro-opach. Najniższy możliwy poziom to ręczna zmiana napięć w
> komórkach pamięci, tworząc różne stany napięć ("bity"), składające się
> na instrukcje ;)
I dla obrony CISC należy przyznać, że tak samo jak RISC wymaga wysyłania 
długiego ciągu instrukcji podstawowych do procesora, tak CISC umożliwia 
wykonanie często spotykanych operacji przy optymalizacji sprzętowej pod 
warunkiem, że operacje złożone zostaną wykorzystane w całości swoich 
funkcji.
-- 
/ qo   |)    :@=N%_g=v=a=g_eD_e=c()=d=8! =%!Gn@8're. w8in/ad
\    _x/ ,   ;h-%-a'hA'H4,X0'Xo~xo~xO,R`-%EXp01ITed: *-7/+eh
/    |    ng `-%__%--'__%--'__%--~__%--^%B`/$qV3r[o; &GooMee
L o_O http://tech.groups.yahoo.com/group/opRWTng O_o L"EnOF"
Message-ID: <f78qr5$6mm$3@inews.gazeta.pl>