Polski procesor ATSD z Warszawy nowy hit tech na CeBIT 2023!

Użytkownik "Michoo" <michoo_news@vp.pl> napisał w wiadomości
news:kh88ul$sbc$1@mx1.internetia.pl...
On 06.03.2013 19:53, Anerys wrote:

W ogóle jest jakaś dziwna tendencja chyba we wszystkim, czy prawie
wszystkim, że praktycznie identyczne, czy podobne programy, obrastają w
craz większy kod wynikowy, nie usprawiedliwiony np. dodawanymi
funkcjami.

W końcu są "różne".

Nie mówię, że nie...


Różne kompilatory dla dokładnie takiego samego kodu
wejściowego produkują całkowicie różny w objętości kod.

A to zależy od wielu opcji czasu kompilacji.

Bezbajerowo. Jeszcze pod DOSem. TP 3 dawał ok. 30 kilku kB, TP7 już
poniżej 10.


Weźmy z Pascala np. (darujcie "interpunkcję", ostatni raz rzeźbiłem 20
lat temu...)
program hello; (niektóre kompilatory OIDP pozwalają na pominięcie tej
deklaracji)
begin
writeln ('Dzien dobry');
end.
jeden kompilator dał 30-kilka kB kodu,

Bardziej rozbudowana lub nie stripowana biblioteka.

Tylko po co ona, gdy jedynym zadaniem programu było krok po kroku
wyrzucić kilkanaście znaków na ekran... w C64 schodziłęm poniżej 50
bajtów włącznie z danymi (fakt, skakałem do podprogramu... ale gdzieś
widziałem listing, który bezpśrednio dawał... i nie obrosło to w zbędny
kod. Ale to w C64 był mus, liczył się każdy bajt. I dobrze.


inny ok. 7,

Mniej rozbudowana (albo np wolniejsza) biblioteka. 30 kB to żaden
rozmiar, więc w czym problem?

Choćby w czasach, w których to robiłem, że taka różnica była istotna. A
jeśli program spokojnie może byc mały, to nie widzę powodów, aby był duży.


A robiły dokładnie to samo. Zero dołączeń,

a writeln to skąd się niby wzięło?

Z treści programu. Nic nie było definiowane w treści przez include,
żadnej dyrektywy dołączającej, nic, poza tymi 4 liniami.


zero innych
deklaracji, itp. a doklejały kilkadziesiąt kB ch.j wie czego, psu na
budę potrzebnego...

A potem jak się trochę więcej napisało to nagle ten pierwszy tył o
dodatkowe kilka kB kodu a ten drugi o kilkadziesiąt.

Klepałem trochę, ale już zapomniałem szczegółów... tylko czemu
wspomniany przeze mnie Zdzich umiał się zachować i nie tył zanadto?

Jestem niemal pewien, że gdyby tu i ówdzie poobcinać fuzle, to programy
zrobiły by się mniejsze... tylko może kompilatory powinny rzetelniej
generować kod? Nie doklejać czegoś, co programowi nie jest potrzebne.

Po grzyba ktoś ma optymalizować kompilator pod kątem minimalnego
programu, który nic nie robi?

Robi - wyświetla na ekranie "Dzien dobry" (bez ogonka, bo wtedy ich
prawie nie znano(1991))
Ja chcę od programu, aby mając tekst j.w., program zrobił:
Licząc od pierwszego do ostatniego znaku, pobrał je po kolei i wyrzucił
na ekran. Niech 100 bajtów kodu pobiera te znaki, drugie 100 wyprowadzi
na ekran, trzecie 100 utrzyma to w całości. Już nie będę aż tak skąpy.

Ale, żeby to nie było po 10 kB, bo co by te 10 kB robiło w swojej części
zadania... czy ile tego było... skoro setka poradziłą sobie równie
dobrze... to co robi pozostałe 9900 bajtów? Ja je chcę wyrzucić. Tylko
tyle.

BTW. Również uważam, że MCS-51 to koszmar programisty.

W dniu 2013-03-04 15:25 JDX napisał(a):

BTW. Również uważam, że MCS-51 to koszmar programisty. :-D

Zgadzam się z powyższym w całej rozciągłości.

Niech ten wynalazek (C) Intel 1980 odejdzie w końcu w niebyt.

Marek Borowski <marek@a.borowski.com> napisał(a):
No wiec jakbys byl kiedys czlonkiem demosceny to bys zrozumial, ze
moga byc inne powody.

Rozumiałem je jeszcze zanim zobaczyłem pierwsze demo. Ale to, że je
rozumiem, nie oznacza, że uważam za słuszne stosowanie ich zawsze i
wszędzie. Z resztą sam fakt, że przywołałeś scenę świadczy o tym, że te
powody są czymś niszowym (niezależnie od tego czy to dobrze czy źle).

Uwzgledniajac realia jak najbardziej sie zgadzam.

Ale co to ma za znaczenie ? Jak juz pisalem w tym watku pojecie "ma
sens" nie jest zwiazane z ekonomia czy czasem pisania programu czy
wysilkiem w to wlozonym. Oceniamy absolutnie. Czyli szybszy i mniejszy
z o tej samej ilosci bledow jest lepszy, niezaleznie czy jego
wywtorzenie zajelo 10lat i kosztowalo 10 mld $ czy nie.

Jest lepszy, tylko często po prostu nie ma to znaczenia.

Oczywiscie. Czepiam sie uzywania kryteriow pozatechnicznych do oceny czy

A jak chcesz rzeźbić to droga wolna - pisałem programy windowsowe,
okienkowe z rozmiarem po skompilowaniu 512-1024B. MASM jest do tego
bardzo wygodny.

A jak chcesz rzeźbić to droga wolna - pisałem programy windowsowe,
okienkowe z rozmiarem po skompilowaniu 512-1024B. MASM jest do tego
bardzo wygodny.

a ja pierszy program pisałem na kartce w assemblerze Z80, na "komputer"
ZX81, który miał 1KB ramu, w czym połowa chyba na pamięć ekranu

Tam się liczył każdy bajt - kto dziś pamięta takie rzeczy
A dodatkowo ten komputer miał od tyłu postawioną suszarkę do włosów,
która nie grzała, ale dmuchała zimnym powietrzem, bo miałem uwalony ULA,
i bez tego po paru minutach się przegrzewał, i zawieszał wszystko w diabły.

A jak chcesz rzeźbić to droga wolna - pisałem programy windowsowe,
okienkowe z rozmiarem po skompilowaniu 512-1024B. MASM jest do tego
bardzo wygodny.

a ja pierszy program pisałem na kartce w assemblerze Z80, na "komputer"
ZX81, który miał 1KB ramu, w czym połowa chyba na pamięć ekranu

Tam się liczył każdy bajt - kto dziś pamięta takie rzeczy

I - co, można było ?? Można !

Użytkownik "sundayman" <sundayman@poczta.onet.pl> napisał w wiadomości
news:khaafm$q0m$1@news.task.gda.pl...
Ale co by nie mówić, na nowszym komputerze render trwa krócej, a nie
dłużej i ostatecznie to właśnie jest finalnym kryterium.

Owszem, tak jest. Ale jakby to dobrze obwąchać, to krócej... ale czy
rzeczywiście o tyle krócej, ile relatywnie wzrosła moc sprzętu?
Uważam, że jeśli moc maszyny wzrosła o 20%, to także o 20% wzrosnąć
powinna szybkość renderu. A jestem niemal pewien, że wzrosła o 10, góóra
15...

Ale co by nie mówić, na nowszym komputerze render trwa krócej, a nie
dłużej i ostatecznie to właśnie jest finalnym kryterium.
Owszem, tak jest. Ale jakby to dobrze obwąchać, to krócej... ale czy
rzeczywiście o tyle krócej, ile relatywnie wzrosła moc sprzętu?
Uważam, że jeśli moc maszyny wzrosła o 20%, to także o 20% wzrosnąć
powinna szybkość renderu. A jestem niemal pewien, że wzrosła o 10, góóra
15...
Dane wzięte z d...? Bo pojawiły się zarówno nowe algorytmy jak i nowe
sposoby programowania (shader anyone?) które przyspieszenie dały nie
rzędu 20% a bardziej 200-2000%. (Kiedyś jedna klatka na kilka -
kilkadziesiąt sekund, teraz 30-40 klatek na sekundę dobrej jakościowo
grafiki na konsumenckim sprzęcie.)

A jak chcesz rzeźbić to droga wolna - pisałem programy windowsowe,
okienkowe z rozmiarem po skompilowaniu 512-1024B. MASM jest do tego
bardzo wygodny.

a ja pierszy program pisałem na kartce w assemblerze Z80, na "komputer"
ZX81, który miał 1KB ramu, w czym połowa chyba na pamięć ekranu

Tam się liczył każdy bajt - kto dziś pamięta takie rzeczy
A dodatkowo ten komputer miał od tyłu postawioną suszarkę do włosów,
która nie grzała, ale dmuchała zimnym powietrzem, bo miałem uwalony ULA,
i bez tego po paru minutach się przegrzewał, i zawieszał wszystko w diabły.

Dane wzięte z d...? Bo pojawiły się zarówno nowe algorytmy jak i nowe
sposoby programowania (shader anyone?) które przyspieszenie dały nie
rzędu 20% a bardziej 200-2000%. (Kiedyś jedna klatka na kilka -
kilkadziesiąt sekund, teraz 30-40 klatek na sekundę dobrej jakościowo
grafiki na konsumenckim sprzęcie.)

a co powiesz na to:
http://microcontroller.com/news/Zilog_Z8051.asp
?
A co powiesz na to (z tego samego newsa): "Last year NXP exited the 8051

A jak chcesz rzeźbić to droga wolna - pisałem programy windowsowe,
okienkowe z rozmiarem po skompilowaniu 512-1024B. MASM jest do tego
bardzo wygodny.

a ja pierszy program pisałem na kartce w assemblerze Z80, na "komputer"
ZX81, który miał 1KB ramu, w czym połowa chyba na pamięć ekranu

Tam się liczył każdy bajt - kto dziś pamięta takie rzeczy

On 2013-03-07 13:35:38 +0100, JDX <jdx@onet.pl> said:

On 2013-03-07 11:11, DJ wrote:
[...]
Generowanie potrzeby na pierdołki - jest głupie, choć potem zyskowne.
No jak jest zyskowne to IMO jest mądre.

Zysk jest kryterium mądrości...?
W tym kontekście jak najbardziej. Przecież celem działania każdego

Głupi są ci, którzy dają się na
takie ściemy nabrać. :-D

Czyli w skrócie:
Kali kraść krowa, być dobrze.
Kalemu ukraść krowa, być źle.
Hę? Ale so chodzi?

Tam się liczył każdy bajt - kto dziś pamięta takie rzeczy :)

A to uzasadnia, jakoś, ze dzisiaj, na x86 należy liczyć każdy bajt? Są
układy gdzie trzeba, chociaż szczerze mówiąc to nawet na attiny 2313 który
ma 128B ram pisałem w C++.

Stwierdzenie "tam się liczył każdy bajt" + hasło 128B zawsze mi się kojarzy