Goto page Previous 1, 2, 3
Zbych
Guest
Tue Jan 02, 2007 11:55 pm
Piotr Wyderski przemówił ludzkim głosem:
Quote:
Ale tylko dzięki wiedzy o sposobie zmian parametrów.
Spróbuj z tym:
I właśnie o to chodziło. Mam wiedzę, której nie ma kompilator i
wykorzystuję ją.
Dlaczego nie miałby postąpić podobnie, gdy widzę, że kompilator słabo
sobie radzi z pewnymi konstrukcjami? I nie zastąpić ich takimi, które
pozwolą wygenerować lepszy kod?
Piotr Wyderski
Guest
Wed Jan 03, 2007 12:03 am
Zbych wrote:
Quote:
Jeżeli to co napiszę w języku wysokiego poziomu spełnia wymagania
Ale masz gwarancję, że spełnia, daną przez np. standard języka?
Jeśli tak, to w porządku.
Quote:
nie widzę powodu, by przenosić to na assembler, tylko dlatego że
kiedyś/gdzieś/ktoś może użyć innej wersji kompilatora, albo chcieć
przenieść to na inny procesor.
Inny procesor to niekoniecznie, ale wiązanie się z określoną
wersją kompilatora to już ciekawe podejście.
Quote:
Sprowadzasz sprawę do absurdu.
Ależ nie, ma całkowitą rację. Projekt, nad którym
ja pracuję ma i wstawki asemblerowe, i wykorzystuje
rozszerzenia kompilatorów, a jednak się te kilka
milionów linii kodu źródłowego bez problemu przenosi
na kilka zupełnie różnych rodzin procesorów, kompiluje
na 4 seriach kompilatorów, w tym GCC, (w każdej serii
jest kilka wersji). Szczerze mówiąc, to nawet by mi
do głowy nie przyszło wiązanie się z określonym
kompilatorem, bo jakiś efekt uboczny generuje pożądany
kod.
Pozdrawiam
Piotr Wyderski
Piotr Wyderski
Guest
Wed Jan 03, 2007 12:05 am
Zbych wrote:
Quote:
Dlaczego nie miałby postąpić podobnie, gdy widzę, że kompilator słabo
sobie radzi z pewnymi konstrukcjami?
Ale to nie kompilator sobie słabo radzi, tylko Ty zmieniłes
algorytm obliczania wyniku. Zadaniem kompilatora jest
przełożenie podanego algorytmu na język maszynowy,
a nie wymyślanie lepszych algorytmów.
Pozdrawiam
Piotr Wyderski
Adam Dybkowski
Guest
Wed Jan 03, 2007 12:35 am
Piotr Wyderski napisał(a):
Quote:
Ależ nie, ma całkowitą rację. Projekt, nad którym
ja pracuję ma i wstawki asemblerowe, i wykorzystuje
rozszerzenia kompilatorów, a jednak się te kilka
milionów linii kodu źródłowego bez problemu przenosi
na kilka zupełnie różnych rodzin procesorów, kompiluje
na 4 seriach kompilatorów, w tym GCC, (w każdej serii
jest kilka wersji). Szczerze mówiąc, to nawet by mi
do głowy nie przyszło wiązanie się z określonym
kompilatorem, bo jakiś efekt uboczny generuje pożądany
kod.
Heh, pewnie nic nigdy nie pisałeś w C na texasowe DSP. Do większości
rodzin nie istnieje gcc więc projektant jest zdany tylko na standardowy
texasowy kompilator. A platforma sprzętowa - istne cudo. :-& Aby napisać
coś przenośnego (co pójdzie i w DSPku, i np. na ARMie), trzeba nieźle
główkować w wielu przypadkach. Na przykład TMS320VC5416 ma architekturę
16-bitową. Więc bajt ma 16 bitów, słowo ma 16 bitów, pamięć jest
podzielona na słowa 16-bitowe. Sizeof zwraca oczywiście wynik w słowach
16-bitowych. Pamięci danych i programu rozdzielone. Naprawdę trzeba od
razu o DSPku myśleć pisząc program, bo potem jest za późno i kod
wygodnie pisany na ARMie ciężko przenosi się na tą konkretną rodzinę TI.
Inna sprawa, że procesory sygnałowe do języka C w ogóle nie zostały
stworzone, ale czasem trzeba go użyć by super zoptymalizowane funkcje
asemblerowe jakoś zgrabnie posklejać.
--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
Goto page Previous 1, 2, 3