LU-MOP-b13

From DiLab
Revision as of 11:39, 10 June 2013 by Leo (talk | contribs) (Kontroldarbi)
Jump to: navigation, search

Mašīnorientētā programmēšana (MOP)

LU DF bakalaura studiju kurss DatZ4017, meklēt eStudijās.


  • Pasniedzējs: Leo Seļāvo (epasts: vards.uzvards @ gmail.com)

Kursa mērķis

Kursa mērķis ir iepazīstināt ar zema līmeņa programmēšanu Asemblerā, ņemot ARM platformu kā konkrētu izstrādes mērķi. Asemblera instrukcijas ir aparatūrai tuvākās procesora izpildes komandas, līdz ar to kursā tiek stāstīts arī par to, kā darbojas procesors, kādi ir tā resursi, un kā to ietekmēt ar Asemblera programmām. Tiek apskatīts arī kā veidot saskarni starp Asembleru un augstāka līmeņa programmām, tai skaitā C.

Vērtējums

Gala vērtējums kursā tiks aprēķināts sekojoši:

  • MK1 + MK2 + MK3 = 25%
  • MD1 = 15%
  • MD2 = 20%
  • KD1 = 20%
  • Eksāmens = 20%

Kalendārs

Datums, nedēļa Kursa saturs Uzdevumi
04.02.2013.

Ievads kursā. Kursa mērķi. Iegultās un mazo procesoru sistēmas. ARM arhitektūra. Mācību izstrādes vide.

11.02.2013.

Sešpadsmitnieku un citas skaitīšatas sistēmas datoriem. Pārveidojumi starp dažādām sistēmām, aritmētiskās darbības. Biti, baiti, vārdi, nibbles.

18.02.2013. Lekcija pārcelta.
25.02.2013.

Procesora uzbūve. Operatīvā atmiņa. Procesora un atmiņas sadarbība. Adreses. Reģistri. Procesora režīmi.

  • Kontroldarbs MK1
04.03.2013.

Skaitļu attēlošana papildkodā.

Programmu izstrādes vide.

11.03.2013.

Programmu izstrādes vide.

"asm1" serveris praktiskajiem darbiem.

  • Kontroldarbs MK2
  • Notiek praktiskie darbi
18.03.2013.

Komandu pieraksts, aritmētiskās un bitu operācijas.

Notiek praktiskie darbi
25.03.2013.

Lieldienu brīvdienas

01.04.2013.

Lieldienu brīvdienas

08.04.2013.

Vadības maiņas komandas, testi, bitu operācijas.

15.04.2013.

Adresācijas režīmi, darbs ar atmiņu.

Kontroldarbs MK3
22.04.2013.

Apakašprogrammu izsaukumi, saskarne ar "C".

29.04.2013.

Simboliskie dati, kodu tabulas.

06.05.2013.

Brīvdiena - jo 4.maijs ir sestdiena

MD1 termiņš 12:00

13.05.2013.

Izteiksmes un makro valoda.

Iekļautais asemblers.

MD1 atkārtotas iesūtīšanas termiņš: trešdien, 15.maijā 12:00, (rezultāts*=0.7)

20.05.2013.

Lielais kontroldarbs KD1

Otrais MD1 atkārtotas iesūtīšanas termiņš: ceturtdien, 23.maijā 12:00, (rezultāts*=0.5)

27.05.2013.

Programmatūras izstrādē lietoto rīku darbības principi.

Instrukciju izpildes laiki.

Sistēmas sāknēšana, priviliģētās operācijas.

Kursa vielas pārskats.

Pasludināts lielais mājas darbs MD2. Termiņš: 14.jūlijs 12:00.

Pasludināts kursa projekts KP.

03.06.2013. un 10.06.2013 MK1,MK2 un MK3 pārrakstīšana, elektroniski.
17.06.2013. 10:00 Eksāmens

 

Kontroldarbi

MK1

Skaitļu formāti un pārvediošana: decimālā, heksadecimālā, oktālā, binārā.

MK2

Skaitļi ar zīmi, divnieka papildkodā, to pārveidošana.

MK3

Asemblera pirmkoda lasīšana un izpratne. Sekot neliela koda fragmentam un noteikt reģistru vērtības pēc tā izpildes.

KD1

Pirmā kontroldarba rezultātu uzlabošanas iespēja.

KD1 bija divi programmēšanas uzdevumi (1. un 3.). Jums iespēja uzlabot savu rezultātu par šiem uzdevumiem iesniedzot tos elektroniski, līdzīgi kā MD1. Iesniegšanas termiņš: 20.jūnijs

1. uzdevums Uzrakstīt no “C” izsaucamu ARM asemblera funkciju

int hex_digit_reverse(char *str, int len)

kas tai padotā virknē str ar garumu len (noslēdzošais '\0' baits netiek garantēts) meklē sešpadsmitnieku ciparus (0–9, a–f, A–F) un apgriež tos pretējā kārtībā, pārējo virknes saturu nemainot. Piemēram, izsaukta uz virkni "Eksaamens nr. 2" tā pārtaisa šo virkni par "2kseamans nr. E".

Uzdevumu iesniegt direktorijā

~/kd1u1


3. uzdevums Uzrakstīt no “C” izsaucamu ARM asemblera funkciju kas, lietojot printf izsaukumus ar formāta virkni "%i\n", dilstošā kārtībā drukā visus “īpašos” naturālos skaitļus, kas ir mazāki par 2^32. Par "īpašiem" sauc tos skaitļus, kuri binārajā pierakstā ir palindromi. Piemēram, skaitlis 1161 = "10010001001" (bināri) ir īpašs.

Uzdevumu iesniegt direktorijā

~/kd1u3

Mājas darbi

MD1

Termiņš: 6.maijs, 12:00

Izveidot programmiņu asemblerā, kas aprēķina aritmētiskās progresijas summu no 1 līdz n ar soli 1.

Skaitlis n tiek padots kā parametrs. Jāizstrādā un jāiesniedz:

  1. Makefile - fails, kas ļauj kompilēt jūsu programmu
  2. md1.h - pirmkoda fails ar funkcijas prototipu, ko iekļaus gan C gan asemblera faili.
  3. md1.s - programmu asemblerā, kas aprēķina aritmētiskās progresijas summu.
  4. md1_main.c - programmu C valodā, kas izsauc asamblera programmu un padod tai parametru n un saņem rezultātu, ko izdrukā uz ekrāna.

Testējot, parametrs n jāpadod no komandu rindas, līdzīgi kā praktisko darbu piemēros.

Tātad, jums būs jāizveido md1_main.c programma, kas saņem parametru caur argv[1], pārveido to par "int", un šis veselais skaitlis jāpadod kā parametrs funkcijai asum(), kas realizēta asemblera kodā, failā md1.s

Rezultāts jāsaņem atpakaļ C programmā un jāizdrukā, piemēram, ar printf() funkciju. Jāizdrukā tikai skaitlis un rindas beigu simbols '\n'.

Piemērs izsaukumam (tam, kā jūsu programma tiks testēta, tikai ar citiem skaitļiem):

leo@asm1:~/work/md1$>  qemu-arm  ./md1 10
55

Risinājums nedrīkst izmantot reizināšanas instrukcijas!

Risinājumam jābūt testētam, un jādarbojās uz asm1.linux.edu.lv servera (arm platformai, emulācijas režīmā).

Risinājumu jāiesūta elektroniski. Risinājumam ar visiem failiem jābūt uz servera asm1.linux.edu.lv jūsu konta direktorijā md1:

~/md1/ 

Uzskaitītie faili tiks izkopēti no minētas direktorijas MD termiņa beigās.

Jautājumus un neskaidrības par MD lūdzu iesūtīt kursa google grupā.


MD2

Matricu reizināšana

Termiņš: 14.jūnijs, 2013.g., 12:00.

Jums, līdzīgi kā MD1, jāizstrādā asemblera procedūra matmul(...), kas reizina divas 2D matricas, un rezultātu ieliek trešajā. Jūsu asemblera programma tiks izsaukta no C valodā rakstītas, tātad parametriem jābūt atbilstošiem.

Zemāk dots programmas izsaukuma piemērs no komadu rindas. Ievaddati tiek padoti ar < operatoru no faila infile.txt uz stdin. Līdzīgi rezultāts no stdout tiek saglabāts izvada failā outfile.txt.

$> md2 < infile.txt > outfile.txt

Jāizstrādā un jāiesniedz sekojoši faili (visi papildus faili tiks ignorēti):

  1. Makefile - fails, kas ļauj kompilēt jūsu programmu
  2. md2.h - pirmkoda fails ar funkcijas prototipu, ko iekļaus gan C gan asemblera faili.
  3. md2.s - programmu asemblerā, kas aprēķina matricu reizinājumu.
  4. md2_main.c - programmu C valodā, kas izsauc asamblera programmu un padod tai matricas, saņem rezultātu, ko izdrukā uz ekrāna.

Matricu ievads

Testējot, matricas jāievada no komandu rindas. Matricas tiek padotas caur stdin, piemēram, no komandu rindas straumējot no teksta faila. Rezultējošā matrica tiek izvadīta uz stdout, ko arī var straumēt uz teksta failu. Arī rezultējošā matrica jāizvada tādā pat formātā kā ievaddati (skat. zemāk).

Matricas teksta failā tiek definētas kā skaitļu virkne. Tātad, jums jānodrošina matricu ievads un izvads sekojošā formātā:

  1. skaitlis H, kas norāda rindu skaitu matricā (augstumu)
  2. skaitlis W, kas norāda kolonu skaitu matricā (platumu)
  3. H*W skaitļi, kas aizpilda matricu, sākot no pirmās rindas.
  4. Pēc tam var sekot nākamā matrica tieši tādā pašā formātā.

Piemēram, 2x3 matrica:

1  2  3
4  5  6

teksta failā var tikt definēta šādi:

2 3
1 2 3
4 5 6

Vai arī šādi, viss vienā rindā. Pārejas uz jaunu rindu nav nepieciešamas un tiek ignorētas, bet tās var saglabāt lasāmības dēļ:

2 3  1 2 3  4 5 6

Skaitļu ievadam C programmā iespējams izmantot funkciju scanf(), piemēram šādi:

#include <stdlib.h>
#include <stdio.h>
 ...
    int  w,h;
    int *matrix, 
    int *p;
 ...
    scanf("%d", &h);
    scanf("%d", &w);
 
    /* Buferu alokācija un cikls pa visiem matricas elementiem */
    matrix = (int*) malloc( w * h * sizeof(int));
    p = matrix;
    for(...)
    {
        scanf("%d", p++);
    }
 ...

Lūdzu ņemiet vērā, ka augšminētais piemērs jāpapildina ar pārbaudēm, lai, piemēram, nekorekti ievaddati nerakstītu ārpus bufera.

Procedūras matmul(...) prototips

int matmul( int h1, int w1, int *m1, int h2, int w2, int *m2, int *m3 );
  • Procedūras parametri: h1 un h2 ir matricas augstums un w1 un w2 ir platums attiecīgi pirmajai un otrajai matricām m1 un m2.
  • Trešās matricas m3 dimensijas nosaka matricu reizinājuma operācija.
  • Procedūra atgriež skaitli int: 0 = veiksmīga izpilde, 1 = problēma, piemēram, nesaderīgas matricas. Šādā gadījumā C programmai arī jābeidz darbs ar kodu 1: exit(1);
  • Visus nepieciešamos datu buferus nodrošina (izveido) izsaucošā C programma, tai skaita arī trešajai, rezultāta matricai. Tas nozīmē, ka arī C programmai jānosaka, cik liela būs rezultāta matrica, lai tai rezervētu pietiekoši daudz atmiņas.

Matricu elementi atmiņā glabājas kā divdimensiju masīvs: Int elementi. Piemēram, 2x3 matrica

1  2  3
4  5  6

atmiņā glabājas lineāri, kā 6 int elementi, katrs izmērā 4 baiti: { 1, 2, 3, 4, 5, 6 }

Visi datu izmēri (atsevišķie skaitļi) saiet int reģistrā, tātad nepārsniedz 4 baitu garumu. Visi skaitļi ir veseli.

Testēšana un iesniegšana

Risinājumam jābūt testētam, un jādarbojās uz asm1.linux.edu.lv servera, lietojot ARM emulatoru qemu-arm. Bez tam, tas, ka risinājums darbojas uz asm1 servera, nenozīmē, ka tajā nav kļūdas un ka par to automātiski pienāktos maksimālais vērtējums. Pieredze rāda, ka reizēm "paveicas", un risinājums darbojas, lai arī tajā ir kļūdas. Testējot vai lietojot to nākamreiz vai uz citas aparatūras tas var nestrādāt. Tāpēc lūdzu pieiet savam kodam kritiski. Piemēram, vai esat saglabājuši un atjaunojuši visus izmantotos reģistrus, sākot no R4 un uz augšu? Šī ir tipiska kļūda, kas var reizēm nostrādāt un reizēm nē.

Risinājumu jāiesūta elektroniski. Risinājumam ar visiem failiem jābūt uz servera asm1.linux.edu.lv jūsu konta direktorijā md2:

~/md2/ 

Uzskaitītie faili tiks izkopēti no minētas direktorijas MD termiņa beigās.

Jautājumus un neskaidrības par MD lūdzu iesūtīt kursa google-grupā.

Kursa projekts

Termiņš: 17.jūnijs, 2013.g., 10:00.

Kursa projekts ir kā alternatīva rakstiskajam eksāmenam. Šogad kursa projekta ietvaros jāizstrādā grafiskā bibliotēka "Agra".

Grafiskās bibliotēkas mērķis ir realizēt efektīvus algoritmus grafisko primitīvu konstruēšanai kadra (frame) buferī.

Jums jāizstrādā asemblera procedūru bibliotēka Agra. Jūsu asemblera programmas tiks izsauktas no C valodā rakstīta pirmkoda, tātad parametriem jābūt atbilstošiem.

Jāizstrādā un jāiesniedz sekojoši faili (visi papildus faili tiks ignorēti):

  1. Makefile - fails, kas ļauj kompilēt jūsu programmu
  2. agra.h - pirmkoda fails ar funkcijas prototipu, ko iekļaus gan C gan asemblera faili.
  3. agra.s - programmu asemblerā, kas realizē grafisko bibliotēku.
  4. agra_main.c - programmu C valodā, kas testē asemblera programmas.
  5. framebuffer.c - programmu C valodā, kas iekļauj kadra bufera piekļuves funkcijas.


Realizējamās funkcijas un datu tipi ir sekojošie:

// Krāsas tips punktam: 
//    r,g,b ir sarkanā, zaļā, un zilā krāsu komponentes, 
//    op  ir operācija, kas jāizpilda šim pikselim ar fona krāsu. 0 - nozīmē rakstīt pāri.
typedef struct {
    unsigned int r  : 10;
    unsigned int g  : 10;
    unsigned int b  : 10;
    unsigned int op: 2;
} pixcolor_t;

// Funkcija krasas (un operācijas) uztādīšanai
void setPixColor( pixcolor_t * color_op);

// Funkcija viena pikseļa uzstadīšanai
void pixel(int x, int y, pixcolor_t * colorop);

// Funkcija līnijas zīmēšanai starp punktiem
void line(int x1, int y1, int x2, int y2);

// Funkcija trijstūra aizpildīšanai ar tekošo krāsu
void triangleFill(int x1, int y1, int x2, int y2, int x3, int y3);

// Funkcija riņķa līnijas zīmēšanai
void circle(int x1, int y1, int radius);

Jūsu funkcijām jāizmanto kadra bufera pieejas funkcijas, kas definētas failā framebuffer.c.

// Kadra bufera sākuma adrese
pixcolor_t * FrameBufferGetAddress();

// Kadra platums
int FrameBufferGetWidth();

// Kadra augstums
int FrameBufferGetHeight();

// Kadra izvadīšana uz "displeja iekārtas".
int FrameShow();

Jūsu gadījumā kadra izvadīšana uz "displeja iekārtas" nozīmē izdrukāt uz ekrāna bufera saturu, kur katram pikselim atbilst viens simbols. Vispārīgā gadījumā šis varētu būt izvads arī uz grafiska LCD ekrāna.

Pikseļu simbolus lūdzu izvēlēties saskaņā ar sekojošām leģendām:

  • melnās krāsas simbols ir tukšums
  • baltās krāsas simbols ir zvaigznīte
  • ja dominē sarkanā krāsa, jāizvada 'R'
  • ja dominē zaļā krāsa, jāizvada 'G'
  • ja dominē zilā krāsa, jāizvada 'B'
  • ja dominē zaļā un zilā krāsa, jāizvada 'C'
  • ja dominē sarkanā un zilā krāsa, jāizvada 'M'
  • ja dominē zaļā un sarkanā krāsa, jāizvada 'Y'


Visos gadījumos, kur nav specificēta funkciju atgriežamā vērtība, bet tās tips ir dots kā int, 0 nozīmē veiksmīgu un 1 - neveiksmīgu izpildi.


Testa demonstrācija

Jūsu izstrādātajam komplektam jādemonstrē bibliotēkas darbība. To var panākt attiecīgi definējot izsaukumus agra_main.c pirmkoda failā, piemēram, no funkcijas main():

  1. definēt ekrāna buferi ar izmēru 40 x 20 (lietojot jūsu framebuffer.c versiju)
  2. notīrīt buferi, aizpildīt katru pikseli ar 0x00000000
  3. zīmēt pikseli koordinātās (25,2), baltu.
  4. zīmēt līniju no (0,0) līdz (39,19), zilu, ar intensitāti 0x03ff
  5. zīmēt aizpildītu trijstūri, zaļu, ar intensitāti 0x03ff
  6. zīmēt riņķa līniju ar centru (20,10) un rādiusu 5, sarkanu, ar intensitāti 0x03ff
  7. izsaukt funkciju FrameShow()

Šis scenārijs jums jārealizē jūsu agra_main.c failā un tiks testēts. Bet tiks testēti arī citi scenāriji, tātad jānodrošina pilna uzskaitīto funkciju funkcionalitāte, pat ja tā nav iekļauta šajā demonstrācijas piemērā.

Kļūdu konstatēšana un apstrāde

Iespējamas sekojošas kļūdas, uz kurām attiecīgi jāreaģē:

  • Tiek zīmēts ārpus kadra - pikseļi ārpus kadra jāignorē.


Testēšana un iesniegšana

Risinājumam jābūt testētam, un jādarbojās uz asm1.linux.edu.lv servera, lietojot ARM emulatoru qemu-arm.

Risinājumu jāiesūta elektroniski. Risinājumam ar visiem failiem jābūt uz servera asm1.linux.edu.lv jūsu konta direktorijā agra:

~/agra/ 

Uzskaitītie faili tiks izkopēti no minētas direktorijas MD termiņa beigās.

Risinājumu jābūt gatavam demonstrēt un izskaidrot eksāmenā.

Jautājumus un neskaidrības par projektu lūdzu iesūtīt kursa google-grupā.


Bieži uzdotie jautājumi

Framebuffer

1) FrameBuffer funkcijas - FrameBufferGetAddress(), FrameBufferGetWidth(), FrameBufferGetHeight() - ir jārealizē pašiem, vai tās tiks iedotas gatavas?


Jums tās nepieciešams realizēt pašiem lai testētu savu darbu. Pēc būtības tās ir vienkāršas - atgriež adresi uz gana lielu buferi un atgriež integer skaitļiem šim buferim. Iesaku kodu parametrizēt, lai varat pārbaudīt dažādiem buferu izmēriem. FrameShow() ir nedaudz sarežģītāka, bet arī tā reducējas uz masīva satura kodēšanu un izdrukāšanu

Protams, darba vērtēšanai būs izveidotas arī speciālas versijas šīm funkcijām, bet to kods nav pieejams.

Frame buffer apskats

2) Kā ir paredzēts ieraudzīt FrameBuffer saturu, strādājot caur SSH?


Iespējami dažādi veidi, jūs savos testos varat izmantot sev piemērotāko. Te būs dažas idejas:

  • hexdump, tekstuāli salasāms izvads uz ekrāna
  • pseido-grafika ar simboliem (piemēram '*' ) pikseļu vietā
  • GDB + Qemu atkļūdošanas režīmā, varat pat skatīties kā buferis aizpildās pa pikseļiem
  • izvads failā.

Nemiet vērā, ka visām šīm speciālajām iespējām gala versijā nav jābūt, piemēram, vērtētājs negaidīs nekādus pēkšņus hexdump uz stdio.

Testēšana

3) Kā notiks uzdevuma testēšana?


Līdzīgi kā MD, automatizēta testēšanas sistēma izmēģinās dažādus izsaukumus bibliotēkai, kā arī versiju ar jūsu izsaukumu.

Bez tam, eksāmena dienā pasniedzējs var izmēģināt jūsu sistēmas darbību.

Sarežģīta matemātika

4) Vai var izmantot kaut kādas C funkcijas, piemēram matemātiskas (tādas, kā sinus)?


Nē, lūdzu neizmantot sin() un tml. sarežģītas funkcijas, lietotājam nav laika gaidīt kamēr katram pikselim tiek rēķināts sinus vai tml. Bez tam, tad jums būtu nepieciešama matemātikas bibliotēka, ko vērtēšanas rīks neplāno iekļaut saišu redaktora bibliotēku sarakstā .

agra_main() saturs

5) Kam ir jabūt agra_main.c failā?


Speciālam piemēram, kas testē visas bibliotēkas funkcijas. Sīkāk skatīt uzdevuma nosacījumos sadaļu: Testa demonstrācija

Testpiemērs

6) Vai jūs varat ielikt vismaz vienu testpiemēru, lai būtu intuitīvi skaidrs, kā apmēram notiks testēšana?


Lūdzu skatīt 3) jautājuma atbildi, kā arī uzdevuma nosacījumos sadaļu: Testa demonstrācija


FrameBuffer un op lauks

7) Kāpēc katram pikselim ir "op" lauks, kurš pēc būtības ir globāls visai bibliotēkai?


Lielisks jautājums. Jā, varētu iztikt bez šī lauka, un attiecīgi paplašināt laukus divām krāsām. Vai arī ieviest šiem bitiem citu nozīmi bufera vai pikseļu matricas (bitmap) pikseļu kontekstā, piemēram, pats buferis varētu noteikt, kāda operācija ar to veicama jaunajiem pikseļiem, vai arī tas varētu būt "caurspīdīguma", vai pat "mirgošanas" bits. Mirgošanu gan parasti paredz teksta un nevis grafiskajiem režīmiem.

Savukārt aparatūrā video kadra atmiņa var tikt realizēta kā 3x10 nevis 32 bitu vārdi.

Projekta kontekstā es atstāju visus krāsu bitu laukus vienāda garuma lai vienkāršotu uzdevumu. Un atdzīstos, ka 2 op biti katram kadra pikselim būs lieki. Tātad, uzdevuma specifikācija nemainās.

Pikseļu reprezentācija testējot

8)

melnās krāsas simbols ir tukšums
baltās krāsas simbols ir zvaigznīte
ja dominē sarkanā krāsa, jāizvada 'R'
ja dominē zaļā krāsa, jāizvada 'G'
ja dominē zilā krāsa, jāizvada 'B'
ja dominē zaļā un zilā krāsa, jāizvada 'C'
ja dominē sarkanā un zilā krāsa, jāizvada 'M'
ja dominē zaļā un sarkanā krāsa, jāizvada 'Y'"

Тas ir nosacījums vai rekomendācija? Zemāk ir minēti vel visādi izvades piemēri... Vai var piemēram lietot 219 (pēc ascii tabulas) simbolu un dažādas teksta krāsas?


Tas ir nosacījums, lai varu testēt jūsu darbus. Jo man būtu grūti uzminēt, vai negaidīti simboli ir kļūda vai plāns. Pārējie piemēri bija jums, kā viela pārdomām, iespējas izvērsties pašiem savā atkļūdošanas procesā, kā arī informācija, kā tādas lietas tiek vai var tikt darītas.

FrameBuffer inicializācija

9) "1. definēt ekrāna buferi ar izmēru 40 x 20 (lietojot jūsu framebuffer.c versiju)"

Framebuffer.c pēc nosacījuma nesatur inicializācijas funkciju. Viņš vispār nesatur nevienu funkciju, kurai var padot bufera izmērus.


Taisnība. Tāpēc viens risinājums ir parametrizēt ekrāna izmērus kompilācijas laikā ar, piemēram,

#define FrameWidth 800


Kuras C funkcijas sauc no asemblera

10) "Frame... funkcijas jāizsauc no asamblera (kaut arī tās ir realizētas C valodā)." FrameShow() arī? Kurā tieši no "specifikācijā norādītajām funkcijām" tas ir jāizdara?


Pajautājiet sev, kuras no funkcijām vajag bibliotēkai asemblerā, un kuras klienta programmai - testētājam?

Show funkcija bibliotēkai nav nepieciešama, bet testētājam/lietotājam gan, kad viss uzzīmēts. Toties bibliotēkai jāzina, cik buferis liels un kur atrodas, lai tajā varētu rakstīt.


#include framebuffer?

11) Ja FrameShow() un nosacīti FrameInit() ir tomēr jāizsauc no C, tad nav skaidrs, kādā veidā agra_main.c par tiem uzzinās.

#include "framebuffer.c" laikam nav pats labākais risinājums.


Nav gan. Vispār #include "*.c" nav labs stils.

Labāk būtu #include "framebuffer.h" Bet tad man jāprasa, lai projektā visiem būtu šāda funkcija.

Alternatīva ir iekļaut framebuffer funkciju prototipus iekš agra.h, nemainot uzdevuma nosacījumus. Tad galvenajai programmai pietiktu ar

#include "agra.h"

lai varētu lietot bibliotēku (nevajadzētu iekļaut abus .h failus). Pie šī risinājuma paliksim kā oficiālā.


Funkciju vērtība neveiksmīgas izpildes gadījumā

12) Kādas ir funkcijas int FrameShow() "neveiksmīgās izpildes"? Jo pēc nosacījuma: "Visos gadījumos, kur nav specificēta funkciju atgriežamā vērtība, bet tās tips ir dots kā int, 0 nozīmē veiksmīgu un 1 - neveiksmīgu izpildi."


Visas tās, ko jūs atradīsiet. Ja funkcijai nav iespējama neveiksmīga izpilde, tā vienmēr atgriež 0.

Eksāmens

Pastāv divi varianti, kā kārtot eksāmenu:

  1. kā kontroldarbu, KD2. Līdzīga sarežģītība un apjoms kā KD1, bet par visu kursa vielu.
  2. kā kursa projektu KP. Šajā gadījumā jāizstrādā programmatūra saskaņā ar kursa projekta aprakstu.

Jums viennozīmīgi jāizvēlas eksāmena forma līdz noteiktam datumam. Pēc tam izvēli mainīt vairs nevarēs. Visi, kas nebūs izvēlējušies līdz tam, rakstīs kontroldarbu KD2.

Varianta izvēle reģistrējama e-studijās, kursa pārbaudījumu sadaļā.

Literatūra

Grāmatas un citi resursi

  • ARM Architecture Reference Manual, ARM DDI 0100I, ARM Limited, 2005.
  • Intel R XScaleTM Microarchitecture Assembly Language Quick Reference Card ARM Instruction Set, Intel Corporation, 2001
  • Intel XScale R Core Developer’s Manual, ON: 273473-002, Intel Corporation, 2004
  • Intel R IXP42X Product Line of Network Processors and IXC1100 Control Plane Processor Developer’s Manual, ON: 252480-006US, Intel Corporation, 2006
  • Patterson and Hennessy, Computer Organization and Design, 4th Edition (@Amazon)
  • "Building Embedded Linux Systems" O'Reilly Media, 2008, ISBN 0596529686

Pamācības

Saites

Atziņas