On Tue, 25 Feb 2014 01:21:14 +0100, Sylwester Łazar <i...@a...pl>
wrote:

>> >> Chcialem zauwazyc niezmialo ze amerykanskich studentow naucza sie
>> >> uzywajac procesora MIPS. Dosyc masowo, MIPS to jakies 80% kursow na
>> >> amerykanskich (i nei tylko amerykanskich) uniwersytetach
>> >
>> >W asm? Jeśli tak to Sylwek się ucieszy bo pic32 to mips ;)
>>
>> W asm.
>>
>> A.L.
>Właśnie się nieco dziwiłem, czytając pozycję:
>"MIPS Assembly Language Programming" Roberta Brittona,
>że jest ona napisana jakby dla studentów.

Tak, ona jest napisana dla studentow, ale to jest podrecznik
pomocniczy.

Podrecznik "glowny" to Computer Organization and Design: The
Hardware/Software Interface, Patterson i Hennessy

Hennessy jest tworca architektury MIPS

Jet wariant tego podrecznika, tych samych autorow: Computer
Architecture: a Quantitative Approach

>Jest tam we wstępie napisane coś takiego:
>" We are assuming that you have experience in developing algorithms, and
>running programs
>in some high level language such as Pascal, C, C++, or JAVA. One of the
>benefits of
>understanding and writing assembly language code is that you will have new
>insights into
>how to write more efficient, high-level language code."
>

To jest prawda. Dobrze sobie zdawac sprawe co kompilator robi z
programem... Ksiazka H&P w sporej czesci traktuje wlasnie o tym
problemie

>Był tam gdzieś fragment też o tym, że dobrym zwyczajem jest zaglądnąć do
>kodu po kompilacji i go poprawić.

Ale to akurat nie ma sensu. Mialo sens 30 lat temu, w dobie Z80. MIPS
i wspoczesne procesory oparte sa o "pipeline architecture". Kompilator
dokonuje znaczacej optymalizacji kodu tak aby jak najlepiej
wykorztstac owa "pipeline". Sprowadza sie to - miedzy innymi, ale nie
tylko - do zmiany kolejnosci wykonywanai instrukcji i przydzielania
rejestrow co wymaga globalnej analizy programu.

Programista niewiele tu moze na poziomie asm zdzialac, a reczne
"poprawki" moga miec katastroficzny skutek. Na przyklad, jednym z
ograniczen NIEKTORYCH wariantow architektury MIPS jest ze jezeli
instrukcja laduje cos z pamieci do rejestru, to rejestr ten nie moze
byc wykorystany w nastepnej instrukcji. Jego wykorzystanie musi byc
opoznione o jedna instrukcje. Jezeli sie o tym nie pamieta/nie wie, to
mozna narozrabiac. Przy okazji kompilator proboje "zatkac" te dziure,
probojac tam wstawic inna instrukcje o ile zaleznosci meidzy danymi na
to pozwola.

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
Answer the following questions:
(1) Is there data hazard in the above code?
(2) If there is data hazard, show how it can be resolved by:
(a) Stalling the pipeline (inserting bubbles)
(b) Inserting nop instructions
(c) Rearranging instructions
Consider 2 cases: with forwarding and without forwarding

Rozpoznanie i likwidacja owego "data hazard" ma znakomity wplyw na
sprawnosc programu. Normalnie robi to kompilator, ale studenci powinni
wiedziec dlaczego kolejnosc wykonywania instrukcji asm nie jest taka
jakby to wynikalo ze struktury programu w C

A.L.

P.S> Jakby sie ktos tym interesowal, to najlepsza ksiazka o zwiazkach
hardware i software jest nastepujaca:

Computer Systems: A Programmer's Perspective, Bryant & O'Hallaron