Użytkownik "Ris" napisał:

================
Oczywiście, że liczyli, liczyli także koszt utrzymania takich
aplikacji, w kontekście dalszego poprawiania, rozwoju. Po prostu koszt
utrzymania, rozwoju kodów źródłowych w assemblerze jest za wysoki w
porównaniu do zysku jakim jest w jakimś tam stopniu mniejsza zajętość
programu. Gdyby patrzeć tak jak ty, kod w assemblerze i kod, np. w c,
to tak, bez sensu przesiadać się na c. Jednak kryteria są też inne.
================

Wiesz to z praktyki, czy tylko ze słyszenia? Słyszysz, że dzwonią tylko
nie wiesz w którym kościele. Pracowałeś we współczesnym 32 bitowym
assemblerze? Twoje opinie może pasują do minionej epoki DOS'a i Win 3x,
ale nie do dzisiejszej rzeczywistości. Masm32 to potężne i sprawne
narzędzie, mogące śmiało konkurować z C. Nie dotyczy to oczywiście
wyższych i nowszych odmian (C++, C#), bo to inna bajka.

Remek

do góry

On 1 Sty, 08:17, "Remek" <w...@n...pl> wrote:

> Pracowałeś we współczesnym 32 bitowym
> assemblerze?

Załóżmy, że rozwijasz swój program w 32-bitowym asemblerze. Program ma
już setki tysięcy linii kodu.

Tymczasem ja mam 64-bitowy procesor i co prawda system operacyjny może
uruchamiać również 32-bitowe programy, ale jest się wtedy ograniczonym
do 2GB pamięci i tylko podstawowe biblioteki systemowe są
zainstalowane w wersji 32-bitowej. Oprócz zmiany wielkości rejestrów
architektura x32_64 oferuje kompilatorowi więcej rejestrów i
adresowanie względem rejestru RIP, co ułatwia tworzenie kodu
niezależnego od adresu, pod którym się znajdzie. Niemal wszystkie
zainstalowane u mnie programy i biblioteki są 64-bitowe; są generowane
z tych samych źródeł, co 32-bitowe. Resztki 32-bitowości są coraz
mniejszym marginesem zachowywanym tylko dla kompatybilności z
programami, które nie są dostępne w źródłach, a producent udostępnia
tylko wersję 32-bitową (acroread, flash, Google Earth).

To jak, piszesz swój program od nowa?

do góry

Użytkownik "Marcin 'Qrczak' Kowalczyk" napisał:

======================================
Załóżmy, że rozwijasz swój program w 32-bitowym asemblerze. Program ma
już setki tysięcy linii kodu.

Tymczasem ja mam 64-bitowy procesor i co prawda system operacyjny może
uruchamiać również 32-bitowe programy, ale jest się wtedy ograniczonym
do 2GB pamięci i tylko podstawowe biblioteki systemowe są
zainstalowane w wersji 32-bitowej. Oprócz zmiany wielkości rejestrów
architektura x32_64 oferuje kompilatorowi więcej rejestrów i
adresowanie względem rejestru RIP, co ułatwia tworzenie kodu
niezależnego od adresu, pod którym się znajdzie. Niemal wszystkie
zainstalowane u mnie programy i biblioteki są 64-bitowe; są generowane
z tych samych źródeł, co 32-bitowe. Resztki 32-bitowości są coraz
mniejszym marginesem zachowywanym tylko dla kompatybilności z
programami, które nie są dostępne w źródłach, a producent udostępnia
tylko wersję 32-bitową (acroread, flash, Google Earth).

To jak, piszesz swój program od nowa?
======================================

Pozdrawiam w Nowym Roku!

Z Tobą nie śmiał bym polemizować, ponieważ znam Twój dorobek i darzę Cię
wielkim szacunkiem. Moje trochę prowokacyjne wypowiedzi odnoszą się do
trolli zaśmiecających wątek. Wypisują bzdury nie mając najmniejszego
pojęcia o czym piszą.

A wracając do tematu. Przetransformowanie 32 bit programu na pełne 64 bit
nie jest proste w żadnym języku. Nie brałem się dotychczas za to i
niewiele mogę powiedzieć. W assemblerze będzie to pewnie żmudne i
pracochłonne. W HLach pewnie zrobi to odpowiedni kompilator (jeśli już
takie są). Problem jest złożony i wart dyskusji. Porównując dawne
programy 16 bit z późniejszymi 32 bit, możemy wyciągać pewne wnioski. W
odniesieniu do 64 bit pewnie trzeba radykalnie zmienić podejście. Chociaż
pewne wnioski co daja większe rejestry można wyciągać na podstawie dawno
już istniejących mechanizmów - MMX/3dnow wykorzystujących 64 bitowe
rejestry, czy 80 bit rejestry FPU. Moim zdaniem ułatwiają operacje na
dużych liczbach i umożliwiają znaczne przyspieszenie takich operacji, co
ma zastosowanie w grafice wektorowej, czy kodekach/dekodekach
audio/video. A takie procedury można wyciągnąć do DLL'i i nie trzeba
przepisywać całego programu. To ciekawy temat.

Pozdrawiam Remek

do góry

TYPE "Marcin 'Qrczak' Kowalczyk":
> On 1 Sty, 08:17, "Remek" <w...@n...pl> wrote:
>> Pracowałeś we współczesnym 32 bitowym assemblerze?
> Załóżmy, że rozwijasz swój program w 32-bitowym asemblerze. Program ma
> już setki tysięcy linii kodu.
>
> Tymczasem ja mam 64-bitowy procesor i co prawda system operacyjny może
> uruchamiać również 32-bitowe programy, ale jest się wtedy ograniczonym
> do 2GB pamięci i tylko podstawowe biblioteki systemowe są zainstalowane
> w wersji 32-bitowej. Oprócz zmiany wielkości rejestrów architektura
> x32_64 oferuje kompilatorowi więcej rejestrów i adresowanie względem
> rejestru RIP, co ułatwia tworzenie kodu niezależnego od adresu, pod
> którym się znajdzie. Niemal wszystkie zainstalowane u mnie programy i
> biblioteki są 64-bitowe; są generowane z tych samych źródeł, co
> 32-bitowe. Resztki 32-bitowości są coraz mniejszym marginesem
> zachowywanym tylko dla kompatybilności z programami, które nie są
> dostępne w źródłach, a producent udostępnia tylko wersję 32-bitową
> (acroread, flash, Google Earth).
>
> To jak, piszesz swój program od nowa?
To ja skorzystam z obecności;-) i zadam pytanie.
Jeśli mamy część sprzętową i część niezależną od sprzętu, to ta niezależna operuje na
symbolach, tak? Ona musi być w rzeczywistości ,klasą abstrakcyjną' czy też szablonem
"C++" (znaczenie, nie składnia)?
--
/ 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://groups.yahoo.com/group/opRWTng O_o_, /L"EnOF"

do góry

On 2 Sty, 18:42, czas dOSa <u...@i...sk> wrote:

> To ja skorzystam z obecności;-) i zadam pytanie.
> Jeśli mamy część sprzętową i część niezależną od sprzętu, to ta niezależna operuje
na symbolach, tak? Ona musi być w rzeczywistości ,klasą abstrakcyjną' czy też
szablonem "C++" (znaczenie, nie składnia)?

Nie rozumiem pytania.

do góry

TYPE "Marcin 'Qrczak' Kowalczyk":
>> To ja skorzystam z obecności;-) i zadam pytanie. Jeśli mamy część
>> sprzętową i część niezależną od sprzętu, to ta niezależna operuje na
>> symbolach, tak? Ona musi być w rzeczywistości ,klasą abstrakcyjną' czy
>> też szablonem "C++" (znaczenie, nie składnia)?
> Nie rozumiem pytania.
Żeby programista mógł napisać niezależną od sprzętu część oprogramowania (czyli
typowo- w języku wysokiego poziomu), nie może używać typów (ograniczmy się wstępnie
do liczbowych) danych związanych ze sprzętem.
Żeby kompilator mógł wytorzyć działającyc program-- musi je znać, gdyż ich użyje w
miejsce abstrakcyjnych typów.
W związku z tym-- pytanie o rzeczywistą realizację: wymyślone typy danych, z ich
własnymi limitami, które następnie są albo dopasowywane do typów danych maszyny, albo
symulowane przez kompilator na maszynie lub w środowisku wykonywania, czy może
analogicznie do prostego "typedef", które tylko zmienia nazwy typów, uniemożliwiając
programiście oparcie się na właściwościach typu zależnego od maszyny.
--
/ 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://groups.yahoo.com/group/opRWTng O_o_, /L"EnOF"

do góry

czas dOSa pisze:
> Żeby programista mógł napisać niezależną od sprzętu część
> oprogramowania (czyli typowo- w języku wysokiego poziomu), nie może
> używać typów (ograniczmy się wstępnie do liczbowych) danych
> związanych ze sprzętem. Żeby kompilator mógł wytorzyć działającyc
> program-- musi je znać, gdyż ich użyje w miejsce abstrakcyjnych
> typów. W związku z tym-- pytanie o rzeczywistą realizację: wymyślone
> typy danych, z ich własnymi limitami, które następnie są albo
> dopasowywane do typów danych maszyny, albo symulowane przez
> kompilator na maszynie lub w środowisku wykonywania, czy może
> analogicznie do prostego "typedef", które tylko zmienia nazwy typów,
> uniemożliwiając programiście oparcie się na właściwościach typu
> zależnego od maszyny.
stdint.h inttypes.h
Używasz tego co potrzebujesz - jeżeli potrzebujesz 32bitową zmienną
całkowitą, bo większego zakresu nie użyjesz, a będzie ich dużo i zależy
ci na upakowaniu danych to piszesz int32_t, jak potrzebujesz zmienną
64bitową, piszesz int64_t i nie przejmujesz się, czy ktoś skompiluje kod
pod i386,amd64, czy avr, bo będzie działał. Jak z to potrzebujesz czegoś
co będzie *minimum* 16 bit, ale ma być możliwie szybkie na tej
platformie (np zmienna lokalna, w której coś liczysz) to używasz
int_fast16_t i na i386 dostajesz int32_t, na amd64 dostaniesz int64_t, a
na avr int16_t.

To jest właśnie potęga C/C++ - jeżeli napisałeś program porządnie to
skompiluje się na wszystkim na co jest kompilator.


--
Pozdrawiam
Michoo

do góry

TYPE "Michoo":
>> Żeby programista mógł napisać niezależną od sprzętu część
>> oprogramowania (czyli typowo- w języku wysokiego poziomu), nie może
>> używać typów (ograniczmy się wstępnie do liczbowych) danych związanych
>> ze sprzętem. Żeby kompilator mógł wytorzyć działającyc program-- musi
>> je znać, gdyż ich użyje w miejsce abstrakcyjnych typów. W związku z
>> tym-- pytanie o rzeczywistą realizację: wymyślone typy danych, z ich
>> własnymi limitami, które następnie są albo dopasowywane do typów danych
>> maszyny, albo symulowane przez kompilator na maszynie lub w środowisku
>> wykonywania, czy może analogicznie do prostego "typedef", które tylko
>> zmienia nazwy typów, uniemożliwiając programiście oparcie się na
>> właściwościach typu zależnego od maszyny.
> stdint.h inttypes.h
> Używasz tego co potrzebujesz - jeżeli potrzebujesz 32bitową zmienną
> całkowitą, bo większego zakresu nie użyjesz, a będzie ich dużo i zależy
> ci na upakowaniu danych to piszesz int32_t, jak potrzebujesz zmienną
> 64bitową, piszesz int64_t i nie przejmujesz się, czy ktoś skompiluje kod
> pod i386,amd64, czy avr, bo będzie działał. Jak z to potrzebujesz czegoś
> co będzie *minimum* 16 bit, ale ma być możliwie szybkie na tej
> platformie (np zmienna lokalna, w której coś liczysz) to używasz
> int_fast16_t i na i386 dostajesz int32_t, na amd64 dostaniesz int64_t, a
> na avr int16_t.
>
> To jest właśnie potęga C/C++ - jeżeli napisałeś program porządnie to
> skompiluje się na wszystkim na co jest kompilator.
A algorytm nie musi być optymalny i kompilator nic z nim już nie zrobi oprócz
usiłowań.
--
/ 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://groups.yahoo.com/group/opRWTng O_o_, /L"EnOF"

do góry

Zawartość nagłówka ["Followup-To:" pl.comp.programming.]
On 03.01.2009, czas dOSa <u...@i...sk> wrote:
> TYPE ?Michoo?:
>>> Żeby programista mógł napisać niezależną od sprzętu część
>>> oprogramowania (czyli typowo?? w języku wysokiego poziomu), nie może
>>> używać typów (ograniczmy się wstępnie do liczbowych) danych związanych
>>> ze sprzętem. Żeby kompilator mógł wytorzyć działającyc program?? musi
>>> je znać, gdyż ich użyje w miejsce abstrakcyjnych typów. W związku z
>>> tym?? pytanie o rzeczywistą realizację: wymyślone typy danych, z ich
>>> własnymi limitami, które następnie są albo dopasowywane do typów danych
>>> maszyny, albo symulowane przez kompilator na maszynie lub w środowisku
>>> wykonywania, czy może analogicznie do prostego ?typedef?, które tylko
>>> zmienia nazwy typów, uniemożliwiając programiście oparcie się na
>>> właściwościach typu zależnego od maszyny.
>> stdint.h inttypes.h
>> Używasz tego co potrzebujesz - jeżeli potrzebujesz 32bitową zmienną
>> całkowitą, bo większego zakresu nie użyjesz, a będzie ich dużo i zależy
>> ci na upakowaniu danych to piszesz int32_t, jak potrzebujesz zmienną
>> 64bitową, piszesz int64_t i nie przejmujesz się, czy ktoś skompiluje kod
>> pod i386,amd64, czy avr, bo będzie działał. Jak z to potrzebujesz czegoś
>> co będzie *minimum* 16 bit, ale ma być możliwie szybkie na tej
>> platformie (np zmienna lokalna, w której coś liczysz) to używasz
>> int_fast16_t i na i386 dostajesz int32_t, na amd64 dostaniesz int64_t, a
>> na avr int16_t.
>>
>> To jest właśnie potęga C/C++ - jeżeli napisałeś program porządnie to
>> skompiluje się na wszystkim na co jest kompilator.
> A algorytm nie musi być optymalny i kompilator nic z nim już nie zrobi oprócz
usiłowań.

Ale o czym ty bredzisz? Algorytmu się nie tworzy tak żeby był najszybszy
co do taktu procesora na wskazanej architekturze, tylko tak, żeby radził
sobie asymptotycznie najszybciej jak się da.

Mógłbyś nie wypowiadać się o tematach, o których nie masz zielonego
pojęcia?

--
Secunia non olet.
Stanislaw Klekot

do góry

> A algorytm nie musi być optymalny i kompilator nic z nim już nie zrobi
> oprócz usiłowań.
Pomoc?:-)
PS Muszę to zrobić do szkoły albo dla szefa.:-) Nie zróbcie mi tego co poprzednio.:-)
Bądźcie ludźmi.;-)
--
/ 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://groups.yahoo.com/group/opRWTng O_o_, /L"EnOF"

do góry