This file is indexed.

/usr/share/doc/HOWTO/pl-html/Assembly-HOWTO.pl.html is in doc-linux-pl-html 2002.06.14-3.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<META HTTP-EQUIV="content-type" content="text/html; charset=iso-8859-2">
<TITLE>Assembly HOWTO</TITLE>


</HEAD>
<BODY>
<H1>Assembly HOWTO<BR></H1>

<H2>Autor: François-René Rideau 
<A HREF="fare@tunes.org">fare@tunes.org</A><BR>
v0.4n, 22 Sierpnia 1998<BR>
<B>Wersja polska: Zbigniew Micha³ Kempczyñski
<A HREF="mailto:wegorz@bydgoszcz.pkobp.pl">wegorz@bydgoszcz.pkobp.pl</A><BR> </B>
v1.0, 30 Stycznia 1999 r. </H2>
<P><HR>
<EM>Dokument ten zosta³ napisany w standardzie ISO-8859-2. Orygina³ tego dokumentu znajduje sie pod adresem 
<A HREF="http://www.tunes.org/~fare/Assembly-HOWTO">http://www.tunes.org/~fare/Assembly-HOWTO</A>.
<EM>To jest
Linux Assembly HOWTO.</EM>
Ten dokument opisuje metody programowania w assemblerze
z u¿yciem <EM>WOLNYCH</EM> narzêdzi programistycznych,
koncentruj±c siê na Systemie Operacyjnym Linux na platformach i386.
Za³±czony materia³ mo¿e, ale nie musi byæ zgodny,
z innym sprzêtem i/lub oprogramowaniem.
Przewodnictwo na tym bêdzie mile widziane.
<EM>S³owa kluczowe</EM>:
        assemblacja, assembler, wolny, makroprocesor, preprocesor,
        asm, inline asm, 32-bitowy, x86, i386, gas, as86, nasm</EM>
<HR>
<H2><A NAME="s1">1. WPROWADZENIE</A></H2>

<H2>1.1 Legal Blurp</H2>

<P>Copyright &copy; 1996,1997,1998 by François-René Rideau.
<P>Ten dokument jest wolnym oprogramowaniem, mo¿esz go redystrybuowaæ
i/lub modyfikowaæ zgodnie z za³o¿eniami GNU General Public License
opublikowanym przez Free Software Foundation;
wersja 2 Licencji, lub (w twoim przypadku) inna pó¼niejsza wersja.
<P>
<H2>1.2 Wa¿na Informacja</H2>

<P>To jest interaktywnie rozwijany dokument: jeste¶ specjalnie proszony do
zadawania pytañ, 
udzielania odpowiedzi na pytania,
poprawiania odpowiedzi,
dodawania nowych odpowiedzi na FAQ, 
wskazywania na inne oprogramowanie, 
wskazywania osobie prowadz±cej b³êdy lub braki na stronach.
Je¶li jeste¶ zmotywowany, móg³by¶
<EM>przej±æ prowadzenie tego HOWTO</EM>.
S³owem, dzia³aj !
<P>By przej±æ prowadzenie skontaktuj siê z kimkolwiek, kto wydaje siê prowadziæ
Assembly-HOWTO. W trakcie tego pisania to jestem ja, np.
<A HREF="mailto:fare@tunes.org">François-René Rideau</A>.
Jakkolwiek, minê³o trochê czasu od kiedy poszukiwa³em mocnego go¶cia
by podmieni³ mnie jako prowadz±cego ten dokument. Niekorzy¶ci± jest to,
i¿ musisz spêdziæ trochê czasu trzymaj±c dokument na czasie, poprawiaj±c go,
i ucz±c siê narzêdzi publikacyjnych LDP. Korzy¶ci± jest to, i¿ zdobêdziesz 
trochê s³awy <EM>i</EM> mo¿esz otrzymaæ wolne kopie kompendiów HOWTO.
<P>
<H2>1.3 Przed s³owem</H2>

<P>Ten dokument ma na celu udzielenie odpowiedzi na najczê¶ciej zadawane pytania przez ludzi,
którzy programuj± lub chc± programowaæ w 32-bitowym assemblerze x86
u¿ywaj±c <EM>wolnych</EM> assemblerów, 
zw³aszcza w systemie operacyjnym Linux.
Mo¿e on tak¿e wskazywaæ inne dokumenty o 
nie-wolnych, nie-x86, lub nie-32-bitowych assemblerach, 
chocia¿ nie jest to jego pierwszorzêdnym celem.
<P>Poniewa¿ g³ównym celem programowania w assemblerze jest budowa 
wnêtrzno¶ci systemów operacyjnych, interpretatorów, kompilatorów, i gier,
gdzie kompilator C zawodzi nie dostarczaj±c potrzebnych ¶rodków wyrazu,
(wykonanie jest coraz rzadszym tematem),
skoncentrujemy siê na rozwoju takiego oprogramowania.
<P>
<H3>Jak u¿ywaæ tego dokumentu</H3>

<P>Ten dokument zawiera odpowiedzi na pewne najczê¶ciej zadawane pytania.
W wielu miejscach, zosta³y umiejscowione adresy URL by wskazaæ na pewne 
oprogramowanie lub magazyny dokumentacji.
<P>Sprawd¼ gdzie s± skopiowane najbardziej u¿yteczne magazyny,
i spróbuj dobraæ siê do najbli¿szej z nich;
uchronisz w ten sposób Internet przed niepotrzebym ruchem w sieci,
i zaoszczêdzisz swój cenny czas.
<P>W szczególno¶ci pewne wielkie magazyny na ca³ym ¶wiecie,
sa kopiami innych popularnych magazynów.
Powiniene¶ siê nauczyæ i zapamiêtaæ miejsca umiejscowione blisko ciebie (roztropno¶æ-sieciowa).
Czasami, lista takich kopii jest wypisana w pliku, 
lub we wiadomo¶ci wej¶ciowej. Miej na uwadze te porady.
W przeciwnym wypadku zapytaj archie o oprogramowaniu którego szukasz...
<P>Naj¶wie¿sze wersje tego dokumentu znajduj± siê w
<A HREF="http://www.tunes.org/~fare/Assembly-HOWTO">http://www.tunes.org/~fare/Assembly-HOWTO</A>
lub
<A HREF="http://www.tunes.org/~fare/Assembly-HOWTO.sgml">http://www.tunes.org/~fare/Assembly-HOWTO.sgml</A><P>ale to co jest w magazynach Linux HOWTO <EM>powinno</EM> byæ tak¿e na czasie 
(ale tego nie wiem):
<P>
<A HREF="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/">ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/</A> (?)
<P>Francuska wersja tego HOWTO mo¿e byæ znaleziona w
<P>
<A HREF="ftp://ftp.lip6.fr/pub/linux/french/HOWTO/">ftp://ftp.lip6.fr/pub/linux/french/HOWTO/</A><P>
<H3>Inne zale¿ne dokumenty</H3>

<P>
<P>
<UL>
<LI>Je¶li nie wiesz czym jest <EM>wolne</EM> oprogramowanie,
proszê przeczytaj <EM>ostro¿nie</EM> GNU General Public License,
która jest u¿ywana w wielu wolnych programach,
i jest pierwowzorem dla wiêkszo¶ci takich licencji.
Ogólnie pojawia siê w pliku o nazwie <CODE>COPYING</CODE>, 
z wersj± biblioteczn± w pliku o nazwie <CODE>COPYING.LIB</CODE>.
Literatura z 
<A HREF="http://www.fsf.org">FSF</A>
(fundacja wolnego oprogramowania) mo¿e tak¿e ci pomóc.
</LI>
<LI>W szczególno¶ci, interesuj±cym rzecz± w takim typie wolnego oprogramowania
przychodz±cego ze ¼ród³ami jest to, i¿ mo¿esz je sprawdziæ, poprawiæ
a tak¿e czasami z nich zapo¿yczyæ. 
Przeczytaj ostro¿nie szczegó³y licencji i skorzystaj.
</LI>
<LI>Jest lista FAQ na comp.lang.asm.x86, która odpowie na wiele ogólnych pytañ
o programowaniu w assemblerze x86, i pytaniach o pewnych komercyjnych
assemblerach w 16-bitowym ¶rodowisku DOS-a.
Pewne z nich zahaczaj± o wolnym 32-bitowym programowaniu, wiêc mo¿esz chcieæ
przeczytaæ to FAQ... 

<A HREF="http://www2.dgsys.com/~raymoon/faq/asmfaq.zip">http://www2.dgsys.com/~raymoon/faq/asmfaq.zip</A>
</LI>
<LI>FAQ-i i dokumenty istniej± o programowaniu na twojej ulubionej platformie,
jakakolwiek ona jest, wiêc powiniene¶ skonsultowaæ tematy specyficzne dla niej 
nie bezpo¶rednio zwi±zane z programowaniem w assemblerze. </LI>
</UL>
<P>
<H2>1.4 Historia</H2>

<P>Ka¿da wersja zawiera kilka napraw i mniejszych korekt,
których nie bêdzie trzeba ci±gle poprawiaæ.
<DL>
<DT><B>Version 0.1      23 Kwiecieñ 1996</B><DD><P>Francois-Rene "Faré" Rideau &lt;fare@tunes.org&gt;
tworzy i publikuje pierwsze mini-HOWTO,
poniewa¿ ``Jestem chory od ci±g³ego odpowiadania na te same pytania
na comp.lang.asm.x86''
<P>
<DT><B>Version 0.2      4 Maj 1996</B><DD><P>*
<P>
<DT><B>Version 0.3c     15 Czerwiec 1996</B><DD><P>*
<P>
<DT><B>Version 0.3f     17 Pa¼dziernik 1996</B><DD><P>*
<P>
<DT><B>Version 0.3g     2 Listopad 1996</B><DD><P>Utworzenie Historii. Dodanie wska¼ników w sekcji o cross-kompilacji.
Dodanie sekcji o programowaniu I/O pod Linux-em (w szczególno¶ci video).
<P>
<DT><B>Version 0.3h     6 Listopad 1996</B><DD><P>wiêcej o cross-kompilacji - Zobacz na sunsite: devel/msdos/ 
<P>
<DT><B>Version 0.3i     16 Listopad 1996</B><DD><P>NASM ³atwo przechodzi
<P>
<DT><B>Version 0.3j     24 Listopad 1996</B><DD><P>wskazanie na t³umaczenie francuskie
<P>
<DT><B>Version 0.3k     19 Grudzieñ 1996</B><DD><P>Co ? Zapomnia³em wskazac na terse???
<P>
<DT><B>Version 0.3l     11 Styczeñ 1997</B><DD><P>*
<P>
<DT><B>Version 0.4pre1  13 Styczeñ 1997</B><DD><P>tekst mini-HOWTO przekszta³ca siê w pe³ne linuxdoc-sgml-owe HOWTO,
by zobaczyæ jak wygl±daj± narzêdzia SGML.
<P>
<DT><B>Version 0.4      20 Styczeñ 1997</B><DD><P>pierwsze jako takie wypuszczenie tego HOWTO.
<P>
<DT><B>Version 0.4a     20 Styczeñ 1997</B><DD><P>do³o¿ono sekcjê Wyrazy Uznania  
<P>
<DT><B>Version 0.4b     3 Luty 1997</B><DD><P>przesuniêcie NASM: teraz jest przed AS86
<P>
<DT><B>Version 0.4c     9 Luty 1997</B><DD><P>Dodano sekcjê "CZY POTRZEBUJESZ ASSEMBLACJI ?"
<P>
<DT><B>Version 0.4d     28 Luty 1997</B><DD><P>Vapor oznajmia o nowym przewodnictwie Assembly-HOWTO.
<P>
<DT><B>Version 0.4e     13 Luty 1997</B><DD><P>Wypuszczenie o DrLinux
<P>
<DT><B>Version 0.4f     20 Marzec 1997</B><DD><P>*
<P>
<DT><B>Version 0.4g     30 Marzec 1997</B><DD><P>*
<P>
<DT><B>Version 0.4h     19 Czerwiec 1997</B><DD><P>wci±¿ wiêcej na temat "jak nie u¿ywaæ assemblacji";
unowocze¶nienie o NASM, GAS.
<P>
<DT><B>Version 0.4i     17 Lipiec 1997</B><DD><P>info o 16-bitowym trybie dostêpu z Linux-a.
<P>
<DT><B>Version 0.4j     7 Sierpieñ 1997</B><DD><P>*
<P>
<DT><B>Version 0.4k     19 Pa¼dziernik 1997</B><DD><P>*
<P>
<DT><B>Version 0.4l     16 Listopad 1997</B><DD><P>wypuszczenie o szóstej edycji LSL.
<P>
<DT><B>Version 0.4m     23 Marzec 1998</B><DD><P>poprawki o wywo³aniu gcc 
<P>To jest jeszcze inne ostatnie-wydanie-przez-Faré-przed-przejêciem-przez-nowego prowadz±cego (?)
<P>
</DL>
<P>
<H2>1.5 Wyrazy Uznania</H2>

<P>Chacia³bym podziêkowaæ nastêpuj±cym osobom, w kolejno¶ci wystêpowania:
<UL>
<LI>
<A HREF="mailto:buried.alive@in.mail">Linus Torvalds</A>
za Linux-a 
</LI>
<LI>
<A HREF="mailto:bde@zeta.org.au">Bruce Evans</A>
za bcc z którego jest wyci±gniêty as86
</LI>
<LI>
<A HREF="mailto:anakin@pobox.com">Simon Tatham</A> i
<A HREF="mailto:jules@earthcorp.com">Julian Hall</A>
za NASM
</LI>
<LI>
<A HREF="mailto:jim-neil@digital.net">Jim Neil</A>
za Zwiêz³o¶æ
</LI>
<LI>
<A HREF="mailto:gregh@sunsite.unc.edu">Greg Hankins</A>
za prowadzenie HOWTO
</LI>
<LI>
<A HREF="mailto:raymoon@moonware.dgsys.com">Raymond Moon</A>
za jego FAQ   
</LI>
<LI>
<A HREF="mailto:dumas@linux.eu.org">Eric Dumas</A>
za t³umaczenie mini-HOWTO na francuski
(smutna rzecz, ¿e autor jest francuzem i pisze po angielsku)
</LI>
<LI>
<A HREF="mailto:paul@geeky1.ebtech.net">Paul Anderson</A>
i
and 
<A HREF="mailto:rahim@megsinet.net">Rahim Azizarab</A>
za pomoc, je¶li nie przejêcie HOWTO.
</LI>
<LI>
<A HREF="mailto:pcg@goof.com">Marc Lehman</A>
za wgl±d w wywo³ania GCC.       
</LI>
<LI>Wszystkim ludziom którzy w³o¿one pomys³y, uwagi i wsparcie moralne.</LI>
</UL>
<P>
<P>
<H2><A NAME="doyouneedasm"></A> <A NAME="s2">2. CZY POTRZEBUJESZ ASEMBLACJI?</A></H2>

<P>No, nie chcia³bym przeszkadzaæ w tym co robisz,
ale tu jest kilka porad ciê¿ko zarobionego do¶wiadczenia.
<P>
<H2>2.1 Za i Przeciw</H2>

<P>
<P>
<H3>Korzy¶ci Assemblacji</H3>

<P>Assemblacja mo¿e wyraziæ mocno niskopoziomowe rzeczy:
<UL>
<LI>masz dostêp do zale¿nych-od-maszyny rejestrów i I/O.
</LI>
<LI>mo¿esz kontrolowaæ dok³adnie zachowanie kodu
w krytycznych sekcjach które mog± wywo³aæ martwe punkty
pomiêdzy wieloma w±tkami programowymi lub urz±dzeniami.  
</LI>
<LI>mo¿esz z³amaæ ustalenia zwyk³ego kompilatora,
który mo¿e pozwalaæ na pewne optymalizacje
(jak chwilowe ³amanie zasad o przydzielaniu pamiêci, 
w±tkach, konwencji wywo³añ, itd).      
</LI>
<LI>mo¿esz budowaæ interfejsy pomiêdzy fragmentami kodu
u¿ywaj±cego pewnych niekompatybilnych konwencji
(np. produkowanego przez ró¿ne kompilatory, 
lub oddzielonego nisko-poziomowym interfejsem).
</LI>
<LI>masz dostêp do nieu¿ywanych trybów twojego procesora 
(np. 16 bitowy tryb interfejsu startowego, instrukcji chip-owych 
(przyp.t³um.) lub dziedziczonego kodu na Intel PC)
</LI>
<LI>mo¿esz produkowaæ rozs±dnie szybki kod dla zwartych pêtli
by poradziæ sobie ze z³ym nie-zoptymalizowanym kompilatorem
(po co, s± przecie¿ dostêpne wolne zoptymalizowane kompilatory!)
</LI>
<LI>mo¿esz produkowaæ kod gdzie
ale tylko na procesorach ze znanym czasem instrukcji,
który ogólnie wy³±cza ca³y przep³yw .... 
</LI>
<LI>mo¿esz produkowaæ rêcznie-zoptymalizowany kod
który jest perfekcyjnie dostosowany do twojej szczególnej konfiguracji sprzêtowej,
a zatem do nikogo wiêcej.
</LI>
<LI>mo¿esz pisaæ pewien kod dla twojego kompilatora nowego jêzyka
(to jest co¶ którzy mog± zrobiæ nieliczni, i tak¿e oni, nie czêsto).</LI>
</UL>
<P>
<P>
<P>
<H3>Niekorzy¶ci Assemblacji</H3>

<P>Assemblacja jest bardzo nisko-poziomowym jêzykiem
(najni¿szym jest rêczne-kodowanie w kodach binarnych instrukcji).
<P>To znaczy
<UL>
<LI>jest d³ugo i monotonnie pisaæ wszystko od pocz±tku,
</LI>
<LI>jest mocno podatna na b³êdy,
</LI>
<LI>b³êdy bêd± bardzo trudne do wy¶ledzenia,
</LI>
<LI>jest to bardzo trudno zrozumieæ i modyfikowaæ,
np. utrzymywaæ
</LI>
<LI>rezultat jest bardzo nie-przeno¶ny na inne architektury,
aktualne i przysz³e,
</LI>
<LI>twój kod bêdzie zoptymalizowany tylko w pewnych implementacjach
na tej samej architekturze:  

dla przyk³adu, po¶ród platform Intelowskich,
ka¿dy wariant CPU i jego odmian
(wzglêdy ukryte, przepustowo¶æ, pojemno¶æ
jednostek obliczeniowych, cache'y, RAM-u, szyny, dysków,
obecno¶ci FPU, rozszerzeñ MMX, itd)   

daje potencjalnie ca³kowicie ró¿ne techniki optymalizacji.   

Warianty CPU ju¿ w³±czone 
Intel 386, 486, Pentium, PPro, Pentium II;
Cyrix 5x86, 6x86; AMD K5, K6.
        
Nowe warianty pojawiaj± siê wiêc nie spodziewaj siê, ¿e ka¿dy listing
twojego kodu bêdzie na czasie.
</LI>
<LI>twój kod mo¿e byæ tak¿e nieprzeno¶ny przez ró¿ne 
platformy systemowe na tej samej architekturze, przez brak w³a¶ciwych narzêdzi
(no, GAS wydaje siê pracowaæ na wszystkich platformach;
NASM wydaje siê pracowaæ lub byæ w stanie pracowaæ na platformach intelowskich).
</LI>
<LI>spêdzisz wiêcej czasu na kilku detalach, 
i nie bêdziesz móg³ skoncentrowaæ siê na ma³ych i du¿ych algorytmach,
które s± w stanie przynie¶æ najwiêksz± czê¶æ przyspieszenia.
[np. mo¿esz spêdziæ trochê czasu buduj±c bardzo szybkie
prymitywy manipulacji na listach/tablicach w assemblerze;
tylko hash-tablice (przyp.t³um.) mog± mocno przyspieszyæ twój program;
lub i innym przypadku, drzewka binarne;
lub pewne wysokopoziomowe struktury rozprowadzane przez klaster 
CPU] 
</LI>
<LI>ma³a zmiana w konstrukcji algorytmu mog³aby ca³kowicie
uniewa¿niæ twój ca³y istniej±cy assemblowany kod.
Tak wiêc tak¿e ty masz byæ gotowy (i w stanie) by przepisaæ to wszystko,
lub bêdziesz przywi±zany do poszczególnych rozwi±zañ algorytmicznych;
</LI>
<LI>W kodzie który nie wypada daleko od standardowych testów, 
komercyjne zoptymalizowane kompilatory wykonuj± prawe rêcznie-kodowany assembler
(no, to jest mniejsz± prawd± na architekturze x86
ni¿ na architekturach RISC-owych;
i byæ mo¿e mniejsz± prawd± ni¿ dla szeroko dostêpnych/wolnych kompilatorach;
jakkolwiek, dla typowego kodu w C, GCC jest ca³kiem dobry);   
</LI>
<LI>I w dowolnym przypadku, jak powiedzia³ wstrzemiê¼liwy John Levine na comp.compilers,
``kompilatory mocno u³atwiaj± u¿ywanie z³o¿onych struktur danych,
i kompilatory nie daj± znudzenia w po³owie drogi
i generuj± ca³kiem dobry kod.''   
One tak¿e bêd± <EM>prawid³owo</EM> przechodziæ transformacje kodu
poprzez ca³y (olbrzymi) program
podczas optymalizacji kodu pomiêdzy procedurami i granicami modu³ów.</LI>
</UL>
<P>
<P>
<H3>Ocenianie</H3>

<P>Podsumowuj±c, chocia¿ mo¿esz uznaæ 
¿e u¿ycie assemblacji jest czasami konieczne,
a nawet po¿yteczne w kilku przypadkach gdzie nie jest konieczne,
bêdziesz chcia³:
<P>
<UL>
<LI>minimalizowaæ u¿ycie kodu assemblera,
</LI>
<LI>hermetyzowaæ ten kod w dobrze zdefiniowanych interfejsach
</LI>
<LI>mieæ kod assemblera generowany automatycznie 
ze wzorców wyra¿onych w wysokopoziomowym jêzyku
ni¿ w assemblerze (np. assemblerowe makra GCC inline)
</LI>
<LI>mieæ narzêdzia automatyzuj±ce t³umaczenie tych programów 
w kod assemblera
</LI>
<LI>mieæ ten kod zoptymalizowany je¶li jest to mo¿liwe
</LI>
<LI>Nade wszystko,
np. pisaæ (rozszerzaæ do) zoptymalizowanych wnêtrzno¶ci kompilatora.</LI>
</UL>
<P>Nawet w przypadkach kiedy Assemblacja jest konieczna (np. rozwój OS)
mo¿esz uznaæ, ¿e nie a¿ do tego stopnia
i trzymaæ siê w/w zasad.
<P>Obejrzyj ¼rod³a j±dra Linux-a zwracaj±c uwagê:
jak ma³o assemblacji jest konieczne,
by uzyskaæ szybki, niezawodny, przeno¶ny, utrzymywalny OS.
Tak¿e udana gra taka jak DOOM zosta³a prawie ca³kowicie napisana w C,
z ma³a czê¶ci± napisan± w assemblerze tylko do przy¶pieszenia jej dzia³ania.
<P>
<H2>2.2 Jak NIE u¿ywaæ Assemblera</H2>

<P>
<P>
<H3>Ogólne zasady uzyskania efektywnego kodu</H3>

<P>Jak rzek³ Charles Fiterman na comp.compilers
o 'cz³owieku kontra kod assemblera wygenerowany przez komputer', 
<P>``Cz³owiek powinien zawsze wygraæ i oto przyczyna.
<UL>
<LI>Po pierwsze cz³owiek pisze ca³o¶æ w jêzyku wysokiego poziomu.
</LI>
<LI>Po drugie zarysowuje gdzie mog± wyst±piæ gor±ce punkty gdzie program spêdza swój czas.
</LI>
<LI>Po trzecie ma kompilator produkuj±cy kod assemblera dla tych ma³ych
sekcji kodu.
</LI>
<LI>Po czwarte rêcznie dostosowuje je by znale¼æ ma³e korzy¶ci 
nad wygenerowanym przez maszynê kodem.</LI>
</UL>

Cz³owiek wygrywa poniewaz umie u¿ywaæ maszyny.''
<P>
<H3>Jêzyki ze zoptymalizowanymi kompilatorami</H3>

<P>Jêzyki takie jak 
ObjectiveCAML, SML, CommonLISP, Scheme, ADA, Pascal, C, C++,
wsród innych,
wszystkie maj± wolne zoptymalizowane kompilatory,
które zoptymalizuj± masê twoich programów,
i czêsto bêd± lepsze ni¿ rêczny kod assemblera nawet dla szczelnych pêtli,
umo¿liwiaj±c ci skoncentrowanie siê na wysokopoziomowych szczegó³ach,
i bez zakazywania ci z³apania
kilku procent wykonania w wy¿ej wymieniony sposób
w momencie gdy osi±gniesz stabilny rozwój.
Oczywi¶cie, s± tak¿e komercyjne zoptymalizowane kompilatory
dla wiêkszo¶ci z tych jêzyków.
<P>Pewne jêzyki maj± kompilatory produkuj±ce kod w C,
który mo¿e byæ dalej zoptymalizowany przez dany kompilator C.
Takimi s± LIST, Scheme, Perl i wiele innych.
Prêdko¶æ jest ca³kiem dobra.
<P>
<H3>Ogólne zasady przy¶pieszania twojego kodu</H3>

<P>W celu przyspieszenia kodu
powiniene¶ robiæ zrobiæ to tylko dla fragmentów programu
które narzêdzie profiluj±ce konsekwentnie okre¶la
jako w±skie gard³o wykonania. 
<P>St±d, je¶li okre¶lisz fragmenty kodu jako zbyt wolne, powiniene¶
<UL>
<LI>najpierw spróbowaæ lepszego algorytmu;
</LI>
<LI>nastêpnie spróbowaæ skompilowaæ go zamiast interpretowaæ;
</LI>
<LI>nastêpnie spróbowaæ w³±czyæ optymalizacje twojego kompilatora;
</LI>
<LI>nastêpnie daæ kompilatorowi wskazówki jak optymalizowaæ
(wypisywanie informacji w LISP-ie; u¿ywanie rejestrów w GCC;
i pe³no innych opcji w wiêkszo¶ci kompilatorów, itd).
</LI>
<LI>nastêpnie mo¿na cofn±æ siê do programowania w assemblerze</LI>
</UL>
<P>Na koñcu, przed zej¶ciem do pisania w assemblerze,
powiniene¶ prze¶ledziæ wygenerowany kod,
sprawdzaj±c czy problem nie le¿y faktycznie w z³ej generacji kodu,
co jest mo¿liwe ale nie w wypadkach:
kod wygenerowany przez kompilator mo¿e byæ lepszy ni¿ móg³byæ napisaæ,
w szczególno¶ci na nowoczesnych architekturach!
Wolne czê¶ci programu mog± byæ równie zagmatwane.
Najwiêkszym problemem nowoczesnych architektur z szybkimi procesorami
s± pewne opó¼nienia dostêpu do pamiêci, nietrafiony dostêp do cache,
i TLB oraz b³êdy stronnicowania;
optymalizacja z u¿yciem rejestrów staje siê wtedy mniej u¿yteczna,
i zyska³byæ wiêcej po przemy¶leniu struktury danych oraz wykorzystuj±c
w±tkowanie gdy¿ uzyska³by¶ lepsze umiejscowienie w dostêpie do pamiêci.
Byæ mo¿e po¼niej dopiero ca³kowicie odmienne spojrzenie na problem, pomo¿e go rozwi±zaæ.
<P>
<H3>Sprawdzanie kodu generowanego przez kompilator</H3>

<P>Jest wiele powodów do sprawdzenia kodu generowanego przez kompilator.
Tu jest zawarte co robiæ z takim kodem:
<UL>
<LI>sprawdziæ czy generowany kod
mo¿e byæ wzmocniony rêcznym kodem assemblera
(lub prze³±czaniem prze³±czników kompilatora)
</LI>
<LI>gdy zachodzi taka mo¿liwo¶æ
rozpocz±æ z tak wygenerowanego kodu i zmodyfikowaæ go;
zamiast rozpoczynaæ wszystko od pocz±tku
</LI>
<LI>bardziej ogólnie, u¿ywaæ generowanego kodu jako kawa³ków do modyfikacji,
który co najmniej daje w³a¶ciw± drogê
twoim funkcjom w assemblerze interfejs do ¶wiata zewnêtrznego 
</LI>
<LI>wy³apaæ b³êdy w kompilatorze (oby jak najrzadziej)</LI>
</UL>
<P>Standardow± metod± uzyskania kodu assemblera 
jest wywo³anie twojego kompilatora z flag± <CODE>-S</CODE>.
Dzia³a to dla wiêkszo¶ci Unix-owych kompilatorów,
w³±czaj±c w to GNU C Compiler (GCC), ale YMMV.
Dla GCC, bardziej zrozumia³y kod assemblera bêdzie wyprodukowany
po u¿yciu opcji <CODE>-fverbose-asm</CODE>.
Oczywi¶cie, je¶li chcesz dostaæ dobry kod assemblera,
nie zapomnij u¿yæ opcji optymalizacji i wskazówek!
<P>
<H2><A NAME="s3">3. ASSEMBLERY</A></H2>

<P>
<P>
<H2>3.1 Inline Assemblera GCC</H2>

<P>Dobrze znany kompilator GNU C/C++ (GCC),
zoptymalizowany 32-bitowy kompilator bêd±cy sercem projektu GNU,
wspiera ca³kiem dobrze architekturê x86,
w³±czaj±c w to zdolno¶æ wstawiania kodu assemblera w programach w C,
w sposób gdzie zarz±dzanie rejestrami mo¿e byæ wyspecyfikowane lub pozostawione GCC.
GCC dzia³a na wiêkszo¶ci dostêpnych platform,
dla godnych uwagi Linux-a, *BSD, VST, OS/2, *DOS-a, WIN*, itd.
<P>
<H3>Gdzie znale¼æ GCC</H3>

<P>Orginalny adres GCC jest adresem FTP GNU
<A HREF="ftp://prep.ai.mit.edu/pub/gnu/">ftp://prep.ai.mit.edu/pub/gnu/</A>
razem ze wszystkimi wersjami aplikacji z projektu GNU.
Przekompilowane i skonfigurowane dla Linux-a wersje s± w 
<A HREF="ftp://sunsite.unc.edu/pub/Linux/GCC/">ftp://sunsite.unc.edu/pub/Linux/GCC/</A>
Istnieje wiele kopii FTP obu adresów,
na ca³ym ¶wiecie a tak¿e na no¶nikach CD.
<P>Rozwój GCC zosta³ podzielony niedawno na dwie czê¶ci.
Wiêcej na temat eksperymentalnej wersji egcs mozna znale¼æ na
<A HREF="http://www.cygnus.com/egcs/">http://www.cygnus.com/egcs/</A><P>¬ród³a przystosowane do twojej ulubionego OS, oraz przekompilowane binaria
mo¿na znale¼æ na zwyk³ych adresach FTP.
<P>Najbardziej popularny port GCC dla DOS-a nosi nazwê DJGPP
i mo¿e byæ znaleziony w katalogach o takiej nazwie na adresach FTP. Zobacz:
<P>
<A HREF="http://www.delorie.com/djgpp/">http://www.delorie.com/djgpp/</A><P>Jest tak¿e port GCC na OS/2 nazwany EMX,
dzia³aj±cy tak¿e pod DOS-em, 
zawieraj±cy wiele bibliotek emuluj±cych wywo³ania funkcji unix-a.
Zobacz:
<P>
<A HREF="http://www.leo.org/pub/comp/os/os2/gnu/emx+gcc/">http://www.leo.org/pub/comp/os/os2/gnu/emx+gcc/</A><P>
<A HREF="http://warp.eecs.berkeley.edu/os2/software/shareware/emx.html">http://warp.eecs.berkeley.edu/os2/software/shareware/emx.html</A><P>
<A HREF="ftp://ftp-os2.cdrom.com/pub/os2/emx09c/">ftp://ftp-os2.cdrom.com/pub/os2/emx09c/</A><P>
<H3>Gdzie znale¼æ dokumentacje GCC Inline Asm</H3>

<P>Dokumentacja GCC zawiera pliki w formacie texinfo.
Mo¿esz przekompilowaæ je TeX-em i wydrukowaæ rezultat,
lub przekonwertowaæ je do .info i ogl±daæ emacs-em,
lub przekonwertowaæ je do .html.
Mo¿esz przekonwertowaæ je (w³a¶ciwymi narzêdziami) do tego co lubisz najbardziej, lub czytaæ takie jakie s±.
Pliki .info s± ogólnie dostarczane z ka¿d± dobr± instalacj± GCC.
<P>W³a¶ciw± sekcj± do sprawdzenia jest:
<CODE>C Extensions::Extended Asm::</CODE>
<P>Sekcja
<CODE>Invoking GCC::Submodel Options::i386 Options::</CODE>
mo¿e byæ ci tak¿e pomocna.
W szczególno¶ci, podaje ci specyficzne ograniczenia nazw rejestrów:
abcdSDB koresponduj± do
<CODE>%eax</CODE>, <CODE>%ebx</CODE>, <CODE>%ecx</CODE>, <CODE>%edx</CODE>,
<CODE>%esi</CODE>, <CODE>%edi</CODE>, <CODE>%ebp</CODE>
wy³±czaj±c (nie ma litery dla <CODE>%esp</CODE>).
<P>Zasoby gier dla DJGPP (nie tylko dla hackerów gier) maj± swoj± stronê
specjalnie o assemblerze:
<P>
<A HREF="http://www.rt66.com/~brennan/djgpp/djgpp_asm.html">http://www.rt66.com/~brennan/djgpp/djgpp_asm.html</A><P>Jest jeszcze strona www nazwana ``DJGPP Quick ASM Programming Guide'',
zawieraj±ca od URL-i do FAQ,
AT&amp;T Sk³adnia ASM x86 ,
Pewne informacje o inline ASM,
i konwertowanie plików .obj/.lib:
<P>
<A HREF="http://remus.rutgers.edu/~avly/djasm.html">http://remus.rutgers.edu/~avly/djasm.html</A><P>GCC zale¿y od GAS podczas assemblacji, i ¶ledzi jego sk³adniê (patrz poni¿ej);
pamiêtaj±c ¿e inline asm wymaga znaków procent podczas cytowania
by mog³y przej¶æ do GAS.
Zobacz poni¿sz± sekcjê o GAS.
<P>Znajdziesz <EM>pe³no</EM> u¿ytecznych przyk³adów w podkatalogu <CODE>linux/include/asm-i386/</CODE>
¼róde³ j±dra Linux-a.
<P>
<H3>Jak w³a¶ciwie wywo³ywaæ GCC z kodem inline assemblera.</H3>

<P>Poniewa¿ funkcje assemblera w ¼ród³ach j±dra
(i bardzo prawdopodobnie twoje w³asne nag³ówki,
je¶li spróbujesz stworzyæ twoje oprogramowanie w assemblerze tak czyste
jak to jest w j±drze linuxa)
s± osadzone w funkcjach <CODE>extern inline</CODE>,
GCC musi zostaæ wywo³±ny z <CODE>-O</CODE> flag (or <CODE>-O2</CODE>, <CODE>-O3</CODE>, itd),
by te funkcje by³y dostêpne.
Je¶li nie, twój kod mo¿e siê skompiluje, ale nie zostanie w³a¶ciwie zlinkowany,
gdy¿ bêdzie szuka³ funkcji <CODE>extern</CODE> które nie s± inline
w bibliotekach z którymi twój program bêdzie linkowany !!!.
Innym sposobem jest zlinkowanie z bibliotekimi zawieraj±cymi wycofane
wersje tych funkcji.
<P>Assemblacja inline mo¿e zostaæ wy³±czona opcj± <CODE>-fno-asm</CODE>,
która ka¿e zaprzestaæ kompilatorowi dzia³ania gdy zostanie u¿yte rozszerzenie sk³adni o inline asm,
w przeciwnym wypadku wygeneruje wywo³anie funkcji zewnêtrznej o nazwie <CODE>asm()</CODE>,
która nie zostanie w³a¶ciwie rozwi±zana przez linker.
Opcja <CODE>-fasm</CODE> przywraca dzia³anie s³owa kluczowego <CODE>asm</CODE>.
<P>Bardziej ogólnie, dobrymi opcjami dla GCC na platformie x86 s±
<HR>
<PRE>
        gcc -O2 -fomit-frame-pointer -W -Wallpp
</PRE>
<HR>
<P><CODE>-O2</CODE> jest dobrym poziomem optymalizacji w wiêkszo¶ci przypadków.
<P>Optymalizacja ponadto zajmuje wiêcej czasu, otrzymuj±c kod który jest mocno d³u¿szy, ale tylko trochê szybszy;
taka optymalizacja mo¿e byæ u¿yteczna tylko dla ciasnych pêtli (je¶li takie s±),
któr± mo¿esz jakkolwiek zrealizowaæ w assemblerze.
W przypadkach gdy koniecznie potrzebujesz silnej optymalizacji ze strony kompilatora dla kilku plików, rozwa¿ u¿ycie <CODE>-O6</CODE>.
<P><CODE>-fomit-frame-pointer</CODE> pozwala generowaæ kod omijaj±cy g³upie
zarz±dzanie ramk± wska¼ników, co daje mniejszy i szybszy kod,
i zwalnia rejestry do dalszych optymalizacji.
Wyklucza to ³atwe u¿ycie narzêdzi odpluskwiaj±cych (<CODE>gdb</CODE>),
ale kiedy chcesz ich u¿yæ, nie martw siê o rozmiar i prêdko¶æ kodu.
<P><CODE>-W -Wall</CODE> w³±cza generowanie wszytkich ostrze¿eñ i pomaga wychwyciæ
g³upie b³êdy.
<P>Mo¿esz dodaæ specyficzne dla danego procecora <CODE>-m486</CODE> lub inne flagi tak, ¿e
GCC wyprodukuje kod bardziej zaadaptowany dla danego komputera.
Zauwa¿, ¿e EGCS (i chyba GCC 2.8) maj± <CODE>-mpentium</CODE> i tego typu flagi,
podczas gdy GCC 2.7.x i starsze wersje nie.
Niez³y wybór flag specyfikuj±cych procesor powinien byæ w j±drze Linux-a.
Sprawd¼ dokumentacjê texinfo o zainstalowanej u ciebie wersji GCC.
<P><CODE>-m386</CODE> pomo¿e zoptymalizowaæ wielko¶æ,
a tak¿e prêdko¶æ na komputerach gdzie pamiêæ jest w pe³ni wykorzystana,
odk±d wielkie programy s± przyczyn± wymiany pamiêci,
jakakolwiek "optymalizacja" jest sensowna dla wiêkszego kodu.
Przy takich ustawieniach, mo¿e byæ pomocne przestanie korzystania z C, 
i w zamian skorzystanie z jêzyka u³atwiaj±cego kod faktoryzuj±cy (przyp.t³um.)
taki jak funkcjonalny jêzyk i/lub FORTH;
i u¿ywaæ implementacji bazuj±cej na wykorzystaniu bajtów i s³ów.
<P>Zapamiêtaj, ¿e mo¿esz u¿ywaæ ro¿nych flag dla ró¿nych plików,
wiêc u¿ywaj maksymalnej optymalizacji tam, gdzie program wykonuje siê najd³u¿ej,
podczas gdy pozosta³e pliki optymalizuj pod wzglêdem rozmiaru.
<P>Do optymalizacji mo¿e byæ pomocna opcja <CODE>-mregparm=2</CODE>
i/lub koresponduj±ce atrybuty funkcji,
ale mog± stwarzaæ wiele problemów podczas linkowania obcego kodu, 
<EM>w³±czaj±æ w to libc</EM>.
S± sposoby by w³a¶ciwie zadeklarowaæ u¿ycie obcych funkcji,
tak, ¿e zostan± wygenerowane w³a¶ciwe wywo³ania,
lecz mo¿esz byæ zmuszony rekompilowaæ obce biblioteki tak,
by u¿ywa³y takich samych konwencji wywo³añ opartych na rejestrach...
<P>Zapamiêtaj, ¿e mo¿esz ustawiæ te flagi jako domy¶lne edytuj±c plik
<CODE>/usr/lib/gcc-lib/i486-linux/2.7.2.3/specs</CODE>
lub gdziekolwiek on jest w twoim systemie (lepiej nie dodawaj tam -Wall).
Dok³adn± lokalizacjê plików specyfikatorów GCC w <EM>twoim</EM> systemie
mo¿esz uzyskaæ wo³aj±æ <CODE>gcc -v</CODE>.
<P>
<H2>3.2 GAS</H2>

<P>GAS jest GNU Assemblerem, na którym opiera siê GCC.
<P>
<H3>Gdzie go znale¼æ</H3>

<P>Znajdziesz go w tym samym miejscu gdzie GCC,
w paczce o nazwie binutils.
<P>
<H3>Jaka jest sk³adnia AT&amp;T </H3>

<P>W zwi±zku z tym, ¿e GAS zosta³ pomy¶lany by wspieraæ 32-bitowe kompilatory unixowe
u¿ywa on standardowej sk³adni ``AT&amp;T'',
która sk³adni± mocno przypomina standardowe assemblery m68k,
i jest standardem w ¶wiecie UNIX-a.
Sk³adnia nie jest ani gorsza, ani lepsza ni¿ sk³adnia ``Intel-owska''.
Jest po prostu inna.
Kiedy bêdziesz zamierza³ u¿ywaæ jej,
zauwa¿ysz bardziej regularna sk³adniê ni¿ w Intel-u,
chocia¿ trochê nudniejsz±. 
<P>Oto najwa¿niejsze ostrze¿enia odno¶nie sk³adni GAS:
<UL>
<LI>Nazwy rejestrów s± poprzedzone <CODE>%</CODE>, wiêc
wygl±d rejestrów <CODE>%eax</CODE>, <CODE>%dl</CODE> itd
zamiast tylko <CODE>eax</CODE>, <CODE>dl</CODE>, itd.
Dziêki temu mo¿liwe jest w³±czanie zewnêtrznych symboli w C bezpo¶rednio
w kodzie assemblera, bez zamieszania i konieczno¶ci 
stosowania okropnych podkre¶leñ jako przedrostków.
</LI>
<LI>Kolejno¶æ operandów jest nastêpuj±ca: pierwsze ¼ród³o, ostatnie przeznaczenie,
w przeciwieñstwie do konwencji intel-a, gdzie pierwsze jest przeznaczenie,
a ostatnie ¼ród³o.
Odt±d, to co w sk³adni intel-a jest <CODE>mov ax,dx</CODE> (wstaw rejestr
<CODE>dx</CODE> w rejestr <CODE>ax</CODE> w sk³adni att bêdzie wygl±da³o nastêpuj±co:
<CODE>mov %dx, %ax</CODE>.</LI>
<LI>D³ugo¶æ operandu jest wyspecyfikowana przez przyrostek w nazwie instrukcji.
Przyrostkiem jest <CODE>b</CODE> dla (8-bitów) bajtu,
<CODE>w</CODE> dla (16-bitów) s³owa, 
i <CODE>l</CODE> dla (32-bitów) podwójnego s³owa.

Na przyk³ad, w³a¶ciw± sk³adni± powy¿szej instrukcji 
bêdzie <CODE>movw %dx,%ax</CODE>.
Jakkolwiek, gas nie wymaga ¶cis³ej sk³adni att,
wiêc przyrostek jest opcjonalny, kiedy d³ugo¶æ operandu mo¿e byæ wywnioskowana z 
rejestrów, w przeciwnym przypadku, domy¶lnie zostanie wstawiony 32-bitowy operand (z ostrze¿eniem).
</LI>
<LI>Wymuszaj±ce operandy zaznaczone s± przyrostkami <CODE>$</CODE>,
tak jak w <CODE>addl $5,%eax</CODE>
(dodaj wymuszaj±ce long dla warto¶æ 5 do rejestru <CODE>%eax</CODE>).
</LI>
<LI>Brak przedrostka w operandzie wskazuje, ¿e jest to adres w pamiêci;
st±d <CODE>movl $foo,%eax</CODE>
wstawia zawarto¶æ <EM>adresu</EM> zmiennej <CODE>foo</CODE> w rejestr <CODE>%eax</CODE>,
ale <CODE>movl foo,%eax</CODE>
wstawia <EM>zawarto¶æ</EM> zmiennej <CODE>foo</CODE> w rejestr <CODE>%eax</CODE>.
</LI>
<LI>Indeksacja lub wskazanie po¶rednie jest realizowane przez umieszczenie 
rejestru indeksowego lub wskazania po¶redniego (komórki wskazania
po¶redniego) w nawiasach,
np <CODE>testb $0x80,17(%ebp)</CODE>
(sprawdza najstarszy bit bajtu o offsecie 17
z komórki wskazanej przez <CODE>%ebp</CODE>). </LI>
</UL>
<P>Istnieje program pomagaj±cy w konwersji programów
ze sk³adni TASM do sk³adni AT&amp;T. Zobacz
<P>
<A HREF="ftp://x2ftp.oulu.fi/pub/msdos/programming/convert/ta2asv08.zip">ftp://x2ftp.oulu.fi/pub/msdos/programming/convert/ta2asv08.zip</A><P>GAS ma obszern± dokumentacjê w formacie TeXinfo,
któr± mo¿na znale¼æ co najmniej w dystrybucji ¼ród³owej.
Przegl±d wyci±gniêtych stron .info z Emacs-a lub innych programów.
Zdarza³y siê pliki o nazwach gas.doc lub as.doc
gdzie¶ w pakietach ¼ród³owych GAS, ale zosta³y w³±czone w dokumentacje TeXinfo.
Oczywi¶cie, w razie w±tpliwo¶ci, alternatywn± dokumentacj±
s± same ¼ród³a!
Sekcj±, która szczególnie ciê zainteresuje to
<CODE>Machine Dependencies::i386-Dependent::</CODE>
<P>Znowu, ¼ród³a Linux-a (j±dra systemu), s± dobrymi przyk³adami;
zobacz w linux/arch/i386, nastêpuj±ce pliki:
<CODE>kernel/*.S, boot/compressed/*.S, mathemu/*.S</CODE>
<P>Je¶li piszesz jaki¶ jêzyk, pakiet obs³ugi w±tków, itd.
mo¿esz obejrzeæ jak inne jêzyki (OCaml, gforth, itd.),
lub pakiety obs³ugi w±tków (QuickThreads, MIT pthreads, LinuxThreads, itd),
lub cokolwiek, zrób to.
<P>Na koñcu, po prostu skompiluj program w C do assemblera
dziêki czemu zobaczysz interesuj±c± ciê sk³adniê.
Zobacz sekcjê 
<A HREF="#doyouneedasm">Czy potrzebujê Assemblacji?</A>.
<P>
<H3>Ograniczony tryb 16-bitowy</H3>

<P>GAS jest 32-bitowym assemblerem, zadaniem którego jest wspomóc 32-bitowy kompilator.
Aktualnie ma on jedno ograniczenie 16-bitowego trybu,
który zawiera niedokoñczone u¿ycie 32-bitowych przedrostków do instrukcji,
tak wiêc piszesz 32-bitowy kod, który chodzi w 16-bitowym trybie na 32 bitowym procesorze.
W obu trybach, wspiera on 16-bitowe u¿ywanie rejestrów,
ale nie wspiera 16-bitowego adresowania.
U¿ycie dyrektywy <CODE>.code16</CODE> and <CODE>.code32</CODE> prze³±cza pomiêdzy trybami.
Zapamiêtaj, ¿e dyrektywa inline assembly
<CODE>asm(&quot;.code16\n&quot;)</CODE>
pozwoli GCC wygenerowaæ 32-bitowy kod, który uruchomi siê w trybie rzeczywistym!
<P>Stwierdzi³em ju¿, ¿e wiêksza czê¶æ kodu potrzebnego do pe³nego wspomagania
16-bitowego trybu programowania zosta³a dodana do GAS przez Bryan'a Ford'a (proszê o potwierdzenie?),
ale ostatecznie, nie pojawi³a siê w ¿adnej dystrybucji któr± sprawdzi³em,
a¿ do binutils-2.8.1.x ... wiêcej informacji na ten temat bêdzie mile widziane.
<P>Cienkim rozwi±zaniem jest definiowanie makr (patrz poni¿ej), które produkuja
kod binarny (z <CODE>.byte</CODE>) który potrzebujesz tylko dla 16-bitowych instrukcji
(prawie ¿adnych je¶li u¿yjesz code16 jak powy¿ej,
i mo¿esz spokojnie za³o¿yæ, ¿e kod bêdzie dzia³a³ na zgodnych 32-bitowych procesorach x86).
By znale¼æ w³a¶ciwe kodowanie, mo¿esz zainspirowaæ siê
¼ród³ami 16-bitowych assemblerami.
<P>
<H2>3.3 GASP</H2>

<P>GASP jest Preprocesorem GAS.
Dodaje makra i trochê milsz± sk³adniê do GAS.
<P>
<H3>Gdzie znale¼æ GASP</H3>

<P>GASP jest zawarty razem z GAS w archiwum GNU binutils. 
<P>
<H3>Jak to dzia³a</H3>

<P>Dzia³a jako filtr, w stylu cpp i jemu podobnym.
Nie pamiêtam szczegó³ów, ale przychodzi on z w³asn± dokumentacj± w texinfo,
wiêc przejrzyj j± (w .info), wydrukuj, prze¶led¼ (?).
GAS z GASP-em wed³ug mnie jest typowym makro-assemblerem.
<P>
<P>
<H2>3.4 NASM</H2>

<P>Projekt Netwide Assembler wypuszcza jeszcze jeden assembler,
napisany w C, który powinien byæ do¶æ modelowy
do ewentualnego wsparcia znanych sk³adni i formatów obiektów.
<P>
<H3>Gdzie znale¼æ NASM</H3>

<P>
<A HREF="http://www.cryogen.com/Nasm">http://www.cryogen.com/Nasm</A><P>Wersja binarna jest na kopii sunsite w 
<CODE>devel/lang/asm/</CODE>
Powinna byæ tak¿e dostêpna jako .rpm lub .deb w dystrybucjach RedHat/Debian
w dystrybucyjnym contrib.
<P>
<H3>Co to robi</H3>

<P>W momencie pisania tego HOWTO, wersja NASM to 0.97.
<P>Sk³adnia jest w stylu Intel-a.
Czê¶æ makroprocesora jest zintegrowana.
<P>Wspierane formaty plików obiektowych to 
<CODE>bin</CODE>, <CODE>aout</CODE>, <CODE>coff</CODE>, <CODE>elf</CODE>, <CODE>as86</CODE>,
(DOS) <CODE>obj</CODE>, <CODE>win32</CODE>, (ich w³asny format) <CODE>rdf</CODE>.
<P>NASM mo¿e byæ u¿ywany jako wspomaganie dla wolnego kompilatora LCC
(pliki wspieraj±ce s± zawarte).
<P>NASM rozwija siê zbyt szybko by to HOWTO by³o aktualne.
Je¿eli nie u¿ywasz BCC jako 16-bitowego kompilatora
(który wykracza poza to 32-bitowe HOWTO),
powiniene¶ u¿ywaæ NASM zamiast powiedzmy AS86 lub MASM,
poniewa¿ jest mocno wspierany online
i chodzi na wszystkich platformach.
<P>Uwaga: NASM przychodzi tak¿e z disassemblerem, NDISASM.
<P>Jego rêcznie napisany parser powoduje, ¿e pracuje szybciej ni¿ GAS,
chocia¿ oczywi¶cie nie wspiera trzech bilionów ró¿nych architektur.
Do x86, on powienien byæ assemblerem wyboru...
<P>
<H2>3.5 AS86</H2>

<P>AS86 jest 80x86 16- i 32-bitowym assemblerem i jest czê¶ci±
kompilatora jêzyka C (BCC) Bruce'a Evans'a. 
Ma on g³ównie sk³adniê Intel-owsk±,
chocia¿ ró¿ni siê nieznacznie np w trybach adresowania.
<P>
<H3>Gdzie dostaæ AS86</H3>

<P>Ca³kowicie przestarza³a wersja AS86 jest dystrybuowana przez HJLu
tylko do kompilacji j±dra Linux-a,
w pakiecie o nazwie bin86 (aktualna wersja 0.4),
dostêpnej w dowolnym magazynie oprogramowania GCC dla Linux-a.
<P>Ale nie radzê nikomu u¿ywania go do czegokolwiek innego ni¿ przekompilowania Linux-a.
Ta wersja wspiera tylko plik obiektowy hacked minix, 
który nie jest wspierany przez GNU binutils ani nic innego,
i ma parê b³êdów w trybie 32-bitowym,
wiêc powieniene¶ lepiej trzymaæ go tylko do kompilacji Linux-a. 
<P>Ostatnie wersje Bruce'a Evans'a (bde@zeta.org.au)
s± publikowane wraz z dystrybucj± FreeBSD.
No, by³y: Nie mogê znale¼æ ¼róde³ z dystrybucji 2.1 na :(
Odt±d, wk³adam ¼ród³a w moim miejscu:
<P>
<A HREF="http:///www.tunes.org/~fare/files/bcc-95.3.12.src.tgz">http:///www.tunes.org/~fare/files/bcc-95.3.12.src.tgz</A><P>Projekt Linux/8086 (aka ELKS) jest w pewnym stopniu pozosta³o¶ci± bcc
(chocia¿ nie s±dze by zawiera³ 32-bitowe ³aty).
Obejrzyj
<A HREF="http://www.linux.org.uk/Linux8086.html">http://www.linux.org.uk/Linux8086.html</A>
<A HREF="ftp://linux.mit.edu/">ftp://linux.mit.edu/</A>.
<P>Miêdzy innymi, ostatnie wersje, w przeciwieñstwie do HJLu's,
wspieraj± Linux-owy format GNU a.out,
wiêc mo¿esz linkowaæ twój kod z programami Linux-owymi, i/lub u¿ywaæ zwyk³ych
narzêdzi z pakietu GNU binutil do manipulacji danymi.
Ta wersja mo¿e ko-egzystowaæ bez szkody z poprzedni± wersj± 
(zobacz poni¿sze pytanie).
<P>BCC z 12 marca 1995 roku i wcze¶niejsze jego wersje maj± brak sk³adnika jakim
jest odk³adanie/pobieranie ze stosu rejestrów segmentowych jako 16-bitowych,
co jest uci±¿liwe gdy programujesz w trybie 32-bitowym.
£ata jest opublikowana w projekcie Tunes
<A HREF="http://www.tunes.org/">http://www.tunes.org/</A>
podstrona
<CODE>files/tgz/tunes.0.0.0.25.src.tgz</CODE>
w rozpakowanym katalogu
<CODE>LLL/i386/</CODE>
£ata powinna byæ tak¿e dostêpna bezpo¶rednio z 
<A HREF="http://www.tunes.org/~fare/files/as86.bcc.patch.gz">http://www.tunes.org/~fare/files/as86.bcc.patch.gz</A>
Bruce Evans zaakceptowa³ tê ³atê, wiêc je¶li którego¶ dnia pojawi siê
nowa wersja bcc, powinna zawieraæ tê ³atê...
<P>
<H3>Jak wywo³aæ assembler?</H3>

<P>
<P>Oto wpis GNU Makefile do u¿ywania bcc
do transformacji <CODE>.s</CODE> asm
w oba GNU a.out <CODE>.o</CODE> obiekt
i <CODE>.l</CODE> listing:
<P>
<HR>
<PRE>
%.o %.l:        %.s
        bcc -3 -G -c -A-d -A-l -A$*.l -o $*.o $&lt;
</PRE>
<HR>
<P>Usuñ <CODE>%.l</CODE>, <CODE>-A-l</CODE>, and <CODE>-A$*.l</CODE>,
je¶li nie chcesz listingu.
Je¶li chcesz czego¶ wiêcej ni¿ GNU a.out, 
mo¿esz przejrzeæ dokumentacjê bcc o wspieranych formatach, 
i/lub u¿yæ objcopy z pakietu GNU binutils.
<P>
<P>
<H3>Gdzie znale¼æ dokumentacje</H3>

<P>Dokumentacje które s±, zawieraj± siê w pakiecie bcc.
Podrêczniki s± tak¿e dostêpne gdzie¶ pod adresem FreeBSD.
Kiedy masz w±tpliwo¶ci, ¼ród³a same w sobie s± czêsto dobr± dokumentacj±:
to nie jest zbyt dobrze komentowane, ale styl programowania jest zrozumia³y. 
Mo¿esz spróbowaæ obejrzeæ jak as86 jest u¿ywany w Tunes 0.0.0.25...
<P>
<P>
<H3>Co je¶li nie mogê ju¿ skompilowaæ Linux-a z now± wersj± ?</H3>

<P>Linus jest zasypywany listami i moja ³ata kompiluj±ca Linux-a
z Linuxowym a.out as86 chyba do niego nie dotar³a (!) (od t³um. trudno to przet³umaczyæ - proszê o poprawki).
Teraz, nie powinno to mieæ znaczenia: trzymaj tylko as86 z pakietu bin86 
w /usr/bin i daj zainstalowaæ bcc dobry as86 w
/usr/local/libexec/i386/bcc/as
gdzie powinien byæ. Nie bêdziesz nigdy wo³a³ wprost tego ``dobrego'' as86,
poniewa¿ bcc robi wszystko w³a¶ciwie, w³±czaj±c konwersjê to Linux-owego a.out,
gdy jest wywo³any z w³a¶ciwymi opcjami;
wiêc assembluj pliki wy³±cznie z bcc jako g³ownym assemblerem, nie bezpo¶rednio z as86.
<P>
<P>
<H2>3.6 INNE ASSEMBLERY</H2>

<P>To s± inne, nieregularne, opcje,
w przypadku, gdy powy¿sze ciê niesatysfakcjonowa³y (dlaczego?),
których nie zalecam w przypadku u¿ytkowania (?),
ale mogê udowodniæ u¿yteczno¶æ je¶li assembler musi byæ zintegrowany
w oprogramowaniu które rozwijasz (np. OS lub aplikacje rozwojowe).
<P>
<P>
<H3>Win32Forth assembler</H3>

<P>Win32Forth jest <EM>wolnym</EM> 32-bitowym systemem ANS FORTH
który dzia³a pod Win32s, Win95, Win/NT.
Zawiera wolny 32-bitowy assembler (zawiera przed/przyrostkow± sk³adniê)
zintegrowany w jêzyku FORTH.
Przetwarzanie makr jest przez
pe³n± moc jêzyka FORTH;
jakkolwiek, jedynym wspieranym wej¶cia i wyj¶cia jest Win32For
(¿adnego zrzutu do plików .obj -- mo¿esz oczywi¶cie dodaæ to samemu).
Znajdziesz to na 
<A HREF="ftp://ftp.forth.org/pub/Forth/win32for/">ftp://ftp.forth.org/pub/Forth/win32for/</A><P>
<P>
<H3>Terse</H3>

<P>Terse jest narzêdziem programowania dostarczaj±cym
<EM>NAJBARDZIEJ</EM> zwart± sk³adnie assemblera
dla rodziny x86!
Zobacz 
<A HREF="http://www.terse.com">http://www.terse.com</A>.
Mówiono, ¿e jest gdzie¶ jaki¶ wolny klon 
który zosta³ porzucony po pustych pretensjach, ¿e sk³adnia
powinna byæ w³asno¶ci± autora;
i zapraszam ciê do przejêcia tego,
je¶li taka sk³adnia ciê interesuje.
<P>
<P>
<H3>Nie-wolne i/lub Nie-32bitowe x86 assemblery.</H3>

<P>Mo¿esz znale¼æ wiêcej o nich,
wraz z podstawami programowania w assemblerze x86
w FAQ Raymond'a Moon'a dla comp.lang.asm.x86
<A HREF="http://www2.dgsys.com/~raymoon/faq/asmfaq.zip">http://www2.dgsys.com/~raymoon/faq/asmfaq.zip</A><P>Zapamiêtaj, ¿e wszystkie bazujace na DOS-ie assemblery powinny pracowaæ w Linuxowym emulatorze DOS-u
tak dobrze jak inne podobne emulatory, wiêc je¶li ju¿ masz jaki¶
mo¿esz go nadal u¿ywaæ w prawdziwym OS.
Ostatnie assemblery bazuj±ce na DOS-ie tak¿e wspieraj± COFF i/lub inne formaty 
plików obiektowych, które s± wspierane przez bibliotekê GNU BFD,
wiêc mo¿esz u¿ywaæ ich razem z wolnymi 32-bitowymi wolnymi narzêdziami,
byæ mo¿e u¿ywaj±æ GNU objcopy (czê¶æ binutils) jako filtr konwertuj±cy.
<P>
<P>
<H2><A NAME="s4">4. METAPROGRAMOWANIE/MAKROPRZETWARZANIE</A></H2>

<P>Assemblacja programów jest nudna,
ale do krytycznych czê¶ci programów.
<P>Powiniene¶ u¿ywaæ w³a¶ciwego narzêdzia do w³a¶ciwego zadania,
wiêc nie wybieraj assemblacji kiedy nie jest stosowna;
C, OCAML, perl, Scheme, mog± byæ lepszym wyborem dla wiêkszo¶ci
twojego programowania.
<P>Jakkolwiek, s± wypadki gdy te narzêdzia nie daj± ci 
wystarczaj±cej kontroli nad maszyn±, i assemblacja jest wtedy u¿yteczna i konieczna.
W takich wypadkach, docenisz system makroprzetwarzania i metaprogramowania
które pozwol± ci wracaæ do raz przygotowanych wzorców z których
ka¿dy z nich jest przygotowany jako wielokrotna definicja,
co pozwala bezpiecznie programowaæ i automatycznie przechodziæ modyfikacjê takich wzorców itd.
"Go³y" assembler jest czêsto niewystarczaj±cy,
nawet je¶li chcesz robiæ tylko ma³e operacje w po³±czeniu z C.
<P>
<H2>4.1 Co jest zintegrowane w powy¿szym</H2>

<P>Tak, wiem ¿e ta sekcja nie zawiera u¿ytecznych informacji.
Masz swobodê do prowadzenia jej, je¶li odkryjesz co¶ ciekawego...
<P>
<P>
<H3>GCC</H3>

<P>GCC pozwala (i wymaga) wyspecyfikowaæ ograniczenia rejestrów
w twoim kodzie ``inline assembly'', wiêc optymalizer zawsze wie o tym.
W ten sposób, assemblacja kodu inline jest tak naprawdê realizowana przez wzorce,
a nie wymuszana. 
<P>Pó¼niej mo¿esz umie¶ciæ twój kod assemblera w makrach CPP,
i funkcjach inline w C,
wiêc ka¿dy mo¿e u¿yæ go jako funkcje w C lub makro.
<P>Funcje inline s± bardzo podobne do makr, ale s± czasami czystsze w u¿yciu.
Strze¿ siê tych wypadków, kod bêdzie zduplikowany,
tak wiêc tylko lokalne etykiety (w stylu <CODE>1:</CODE>) powinny byæ definiowane w kodzie assemblera.
Jakkolwiek, makro powinno pozwoliæ nazwie dla nie lokalnej etykiety
byæ przekazan± jako parametr (lub inaczej, powinienes u¿ywaæ dodatkowych
meta-programowych metod).
Zapamiêtaj tak¿e, ¿e rozej¶cie siê kodu jako inline assemblera bêdzie potencjalnie rozprowadza³ nim b³êdy, 
wiêc uwa¿aj dok³adnie w kwestii ograniczeñ rejestu w kodzie inline asm.
<P>Ostatecznie, jêzyk C w sobie mo¿e byæ rozwa¿any jako dobra abstrakcja 
programowania w assemblerze,
co przyniesie ci ulgê z wiêkszo¶ci± k³opotów z assemblacj±.
<P>Strze¿ siê pewnych optymalizacji które zawile przekazuj± argumenty do funkcji;
przez rejestry mog± powodowaæ niedopasowanie tych funkcji do wywo³añ 
z zewnêtrznych (w szczególno¶ci rêcznie napisanego kodu assemblera) funkcji
w standardowy sposób; atrybut "asmlinkage" mo¿e chroniæ 
funkcjê przed k³opotami z tak± flag± optymalizacyjn±;
obejrzyj ¼ród³a j±dra linux-a dla przyk³adów.
<P>
<H3>GAS</H3>

<P>GAS ma mo¿liwo¶æ w³±czania pewnych makr, jak opisano w dokumentacji texinfo.
Oprócz tego, podczas gdy GCC rozpoznaje pliki .s jako surowy assembler do wys³ania do GAS,
tak¿e rozpoznaje pliki .S jako pliki do przepuszczenia przez CPP przed
wpuszczeniem ich do GAS.
Znowu, znowu, zobacz ¼ród³a Linux-a dla przyk³adów.
<P>
<P>
<H3>GASP</H3>

<P>Dodaje wszelkie u¿yteczne dodatki makroassemblacji do GAS.
Obejrzyj jego dokumentacjê texinfo.
<P>
<P>
<H3>NASM</H3>

<P>NASM tak¿e zawiera pewne wsparcie makr.
Zobacz dokumentacjê.
Je¶li masz jakie¶ dobre pomys³y,
mo¿esz chcieæ skontaktowaæ siê z autorami,
jako, ¿e oni aktywnie go rozwijaj±.
W miêdzyczasie, zobacz poni¿ej zewnêtrzne filtry.
<P>
<P>
<H3>AS86</H3>

<P>On tak¿e ma trochê prostego wsparcia makrami, ale nie mog³em nigdzie znale¼æ dokumentacji.
Teraz ¼ród³a s± bardzo przejrzyste,
wiêc je¶li jeste¶ zainteresowany, ³atwo powieniene¶ je zrozumieæ.
Je¶li potrzebujesz wiêcej ni¿ tylko bazê, powiniene¶ u¿yæ zewnêtrznego filtra
(zobacz poni¿ej).
<P>
<P>
<H3>INNE ASSEMBLERY</H3>

<P>
<UL>
<LI>Win32FORTH:
CODE i END-CODE s± normalne wiêc nie prze³±czaj ich z trybu interpretacji
to trybu kompilacji, bêdziesz mia³ wtedy dostêp do ca³ej mocy FORTH
podczas assemblacji.</LI>
<LI>TUNES:
nie dzia³a jeszcze, ale jêzyk Scheme jest prawdziwym wysokopoziomowym jêzykiem
który pozwala na meta-programowanie.</LI>
</UL>
<P>
<P>
<H2>4.2 Zewnêtrzne Filtry</H2>

<P>Jakiekolwiek jest wsparcie makr twojego assemblera,
lub jakikolwiek jêzyk u¿ywasz (nawet C !),
je¶li jêzyk nie jest dla ciebie wystarczaj±co wyrazisty,
mo¿esz chcieæ przepu¶ciæ pliki przez zewnêtrzny filtr
z regu³ami w Makefile takimi jak te:
<P>
<HR>
<PRE>
%.s:    %.S other_dependencies
        $(FILTER) $(FILTER_OPTIONS) &lt; $&lt; > $@
</PRE>
<HR>
<P>
<P>
<H3>CPP</H3>

<P>CPP nie jest bardzo wyrazisty, ale wystarczaj±cy do wielu ³atwych rzeczy,
jest standardem, i jest przezroczy¶cie wywo³ywany przez GCC.
<P>Dla przyk³adu jego ograniczeñ, nie mo¿esz deklarowaæ obiektów, takich ¿e
destruktory wywo³ywane automatycznie na koñcu deklarowanego bloku;
nie mo¿esz wiêc zmieniaæ kierunki widoczno¶ci, itd. 
<P>CPP przychodzi wraz z kompilatorem C. Je¶li móg³by¶ robiæ to bez niego,
nie zawracaj sobie g³owy przynoszeniem CPP (chocia¿ my¶lê jakby¶ móg³).
<P>
<P>
<H3>M4</H3>

<P>M4 daje ci pe³n± moc makroprzetwarzania, 
z jêzykiem równym Turingowi, rekursj±, wyra¿eniami regularnymi, itd.
Mo¿esz robiæ wszystko czego CPP nie.
<P>Zobacz macro4th/This4th z
<A HREF="ftp://ftp.forth.org/pub/Forth/">ftp://ftp.forth.org/pub/Forth/</A> in Reviewed/ ANS/ (?),
lub ¼ród³a Tunes 0.0.0.25 jako przyk³ady 
zaawansowanego makroprogramowania z u¿yciem m4.
<P>Jakkolwiek, jego niefunkcjonalna semantyka cytowania i odcytowywania zmusza ciê do u¿ywania
jawnego ogonkowo-kontynuacyjno-przej¶ciowego (przyp. t³um.) stylu makr je¶li
chcesz robiæ <EM>zaawansowane</EM> makro programowanie
(czego przypomnieniem jest TeX -- BTW, czy kto¶ próbowa³ u¿ywaæ TeX-a jako
makroprocesora do czego¶ innego ni¿ typesetting ?)
To NIE jest gorsze ni¿ CPP, który nie pozwala na cytowanie i rekursjê.
<P>W³a¶ciw± wersj± m4 jest GNU m4 1.4 (lub pó¼niejsza je¶li istnieje)
która zawiera wiêkszo¶æ sk³adników i mniej b³êdów lub ograniczeñ.
m4 zosta³ pomy¶lany jakko wolny do czegokolwiek ale prosty w u¿yciu,
mo¿e byæ wiêc nadal dobry dla wiêkszo¶ci programów w assemblerze
(chyba nie piszesz programów z milionami linii w assemblerze?).
<P>
<P>
<H3>Makroprzetwarzanie z twoim w³asnym filtrem</H3>

<P>Mo¿esz pisaæ twój w³asny prosty filtr rozszerzaj±cy makra
z u¿yciem zwyk³ych narzêdzi: perl, awk, sed, itd.
To jest szybki sposób i mo¿esz wszystko kontrolowaæ.
Ale oczywi¶cie, moc makroprzetwarzania musi co¶ kosztowaæ.
<P>
<P>
<H3>Metaprogramowanie</H3>

<P>Zamiast u¿ywania zewnêtrznych filtrów które rozszerzaj± makra, 
jedn± z dróg jest pisanie programów, które pisz± czê¶æ
lub ca³o¶æ innych programów.
<P>Dla przyk³adu, móg³by¶ u¿yæ programu produkuj±cego kod ¼ród³owy
<UL>
<LI>do generowania tablic sinus/cosinus/cokolwiek,</LI>
<LI>do wyci±gania reprezentacji ¼ród³owej pliku binarnego,</LI>
<LI>do kompilacji bitmap w szybkie funkcje wy¶wietlaj±ce,</LI>
<LI>do wyci±gania dokumentacji, kodu pocz±tkowego/koñcowego,
tablic opisowych, tak dobrze jak normalnego kodu z samych plików ¼ród³owych,</LI>
<LI>do zwyk³ego kodu assemblera, generowanego ze skryptów perl/shell/scheme
które robi przetwarzanie,</LI>
<LI>do rozchodzenia danych zdefiniowanych w jednym punkcie
w ró¿ne krzy¿owe wg odwo³añ tablice i nag³ówki.</LI>
<LI>itd.</LI>
</UL>

Pomy¶l o tym!
<P>
<P>
<H3>Czê¶æ wspomagaj±ca z dostêpnych kompilatorów</H3>

<P>Kompilatory takie jak SML/NJ, Objective CAML, MIT-Scheme, itd,
maj± w³asn± czê¶æ wspomagaj±c± assembler,
któr± mo¿esz ale nie musisz wykorzystywaæ,
je¶li zamierzasz generowaæ kod pó³automatycznie
z wymienionych jêzyków.
<P>
<P>
<H3>Zestaw narzêdzi Machine-Code z New-Jersey</H3>

<P>Jest projekt, u¿ywaj±cy jêzyka programowania Icon,
do budowy podstawowych rzeczy do produkcji manipulacji na kodzie assemblera.
Zobacz
<A HREF="http://www.cs.virginia.edu/~nr/toolkit/">http://www.cs.virginia.edu/~nr/toolkit/</A><P>
<P>
<H3>Tunes</H3>

<P>Projekt Tunes OS rozwija swój w³asny assembler
jako rozszerzenie jêzyka Scheme i 
jako czê¶æ procesu rozwojowego.
Nie dzia³a to jeszcze, ale pomoc jest widziana.
<P>Assembler manipuluje symbolicznymi drzewami sk³adni,
wiêc mo¿esz prawie mieæ podstawê do translacji sk³adni assemblera, 
disassembler, wspóln± czê¶æ wspomagaj±c± assembler/kompilator, itd.
Tak¿e, pe³na moc jêzyka Scheme
czyni go nie do pokonania z makroprzetwarzaniem/metaprogramowaniem.
<P>
<A HREF="http://www.tunes.org/">http://www.tunes.org/</A><P>
<P>
<H2><A NAME="s5">5. KONWENCJE WYWO£AÑ</A></H2>

<P>
<P>
<P>
<H2>5.1 Linux</H2>

<P>
<P>
<H3>Po³±czenie z GCC</H3>

<P>To jest preferowany sposób.
Sprawd¼ dokumentacjê i przyk³ady GCC z plików <CODE>.S</CODE> j±dra Linux-a
które s± przepuszczane przez gas (nie takie, które s± przepuszczane przez as86).
<P>32-bitowe argumenty s± odk³adane na stos w odwrotnej kolejno¶ci wystêpowania
(st±d dostêp / pobieranie jest we w³a¶ciwej kolejno¶ci),
zwracaj±c bliski 32-bitowy adres. 
<CODE>%ebp</CODE>, <CODE>%esi</CODE>,
<CODE>%edi</CODE>, <CODE>%ebx</CODE> s± zapamiêtywane, 
inne rejestry te¿ s± zapamiêtywane podczas wywo³ania;
<CODE>%eax</CODE> jest u¿ywany do przechowywania wyniku,
a <CODE>%edx:%eax</CODE> do przechowywania wyników 64-bitowych.
<P>FP stack: Nie jestem pewien,
ale my¶lê ¿e wynik jest w <CODE>st(0)</CODE>, ca³y stos jest zapamiêtany.
<P>Pamiêtaj, ¿e GCC ma opcje modyfikuj±ce konwencje wywo³añ
przez rezerwowanie rejestrów, przekazywanie argumentów w rejestrach,
nie u¿ywanie FPU, itd. Sprawd¼ strony .info i386.
<P>Pamiêtaj, ¿e musisz zadeklarowaæ atrybut <CODE>cdecl</CODE>
dla funkcji u¿ywaj±cych standardowej konwencji wywo³añ GCC
(nie wiem co daje u¿ycie zmodyfikowanej konwencji wywo³añ).
Zobacz w stronach info GCC sekcjê:
<CODE>C Extensions::Extended Asm::</CODE>
<P>
<P>
<P>
<H3>ELF kontra a.out - problemy</H3>

<P>Pewne kompilatory poprzedaj± podkre¶leniem ka¿dy symbol,
podczas gdy inne nie.
<P>W szczególno¶ci, Linux-owy GCC a.out ma takie poprzedniki,
podczas gdy Linux-owy ELF GCC nie.
<P>Je¶li musisz poradziæ sobie z wykorzystaniem obu formatów
zobacz jak robi± to istniej±ce pakiety.
Dla przyk³adu, we¼ stare drzewo ¼ród³owe Linux-a
z pakietami Elk, qthreads lub OCAML...
<P>Mo¿esz tak¿e nadpisaæ niejawnie C<CODE>-&gt;</CODE>asm zmieniaj±c nazwê
przez wstawienie wyra¿eñ takich jak to
<HR>
<PRE>
        void foo asm(&quot;bar&quot;) (void);
</PRE>
<HR>

by upewniæ siê, ¿e wywo³anie funkcji C foo bêdzie zabronione w assemblerze.
<P>Zapamiêtaj, ¿e program <CODE>objcopy</CODE>, z pakietu <CODE>binutils</CODE>,
powinien pozwoliæ ci przekonwertowaæ obiekty a.out w obiekty ELF,
i byæ mo¿e w przeciwn± stronê tak¿e, w pewnych wypadkach.
Bardziej ogólnie, program ten realizuje konwersjê formatów wielu plików.
<P>
<P>
<H3>Bezpo¶rednie wywo³ania systemowe Linux-a</H3>

<P>To <EM>NIE</EM> jest rekomendowane, 
poniewa¿ konwencje zmieniaj± siê od czasu do czasu
od j±dra do j±dra (cf L4Linux),
dodatkowo to nie jest przeno¶ne,
i niezyskowne w pisaniu bior±c pod uwagê libc,
I wy³±cza poprawki i rozszerzenia które pojawiaj± siê w libc,
takie, jak np. biblioteka <CODE>zlibc</CODE>,
która w locie przezroczy¶cie dekompresuje spakowane gzip-em pliki.
Standardem i rekomendowan± drog± wywo³añ systemowych us³ug Linux-a jest
i tak zostanie, przej¶cie przez libc.
<P>Obiekty dzielone powinny trzymaæ twoje programy ma³ymi.
I je¶li naprawdê chcesz mniejszych binariów, u¿ywaj <CODE>#!</CODE> ,
z interpretera maj±cego nad sob± wszystko czego nie chcesz w swoich
binariach.
<P>Teraz, je¶li z pewnych powodów
nie chcesz linkowaæ programów z libc
we¼ siê za ni± i zrozum jak dzia³a!
Po tym wszystkim, nadal zamierzasz zamieniæ j± ?
<P>Mo¿esz zerkn±æ tak¿e jak mój
<A HREF="ftp://ftp.forth.org/pub/Forth/Compilers/native/unix/Linux/linux-eforth-1.0c.tgz">eforth 1.0c</A>
robi to.
<P>¬ród³a Linux-a s± tak¿e u¿yteczne, 
szczególnie plik nag³ówkowy asm/unistd.h 
który opisuje jak wywo³ywaæ funkcje systemowe...
Podstawowo, wywo³ujesz  <CODE>int $0x80</CODE>
z <CODE>__NR_</CODE>numerem funkcji systemowej (z <CODE>asm/unistd.h</CODE>)
w <CODE>%eax</CODE>,
i parametrami (do piêciu) w 
<CODE>%ebx</CODE>, <CODE>%ecx</CODE>, <CODE>%edx</CODE>,
<CODE>%esi</CODE>, <CODE>%edi</CODE>.
Rezultat jest zwracany w <CODE>%eax</CODE> 
z warto¶ci± ujemn± w przypadku b³êdu
której przeciwn± warto¶æ libc umieszcza w errno.
Stos u¿ytkownika jest nietkniêty
wiêc nie musisz mieæ go w³a¶ciwego podczas wywo³ania systemowego.
<P>
<P>
<H3>I/O pod Linux-em</H3>

<P>Je¶li chcesz korzystaæ bezpo¶rednio z I/O pod Linux-em
jest co¶ prostego co nie uzale¿nia od OS,
i powiniene¶ obejrzeæ  <CODE>IO-Port-Programming</CODE> mini-HOWTO;
lub potrzebuje to sterownik urz±dzenia, powiniene¶ spróbowaæ nauczyæ siê o
³amaniu j±dra, rozwijaniu sterowników urz±dzeñ, modu³ów j±dra itd,
dla których s± inne wspania³e HOWTO i dokumenty z LDP.
<P>W szczególno¶ci, je¶li chcesz zaj±æ siê programowaniem Grafiki
przy³±cz siê do projektu GGI:
<A HREF="http://www.ggi-projectorg/">http://www.ggi-projectorg/</A><P>Jakkolwiek, we wszystkich przypadkach, zrobisz lepiej u¿ywaj±c GCC inline assembly
z makrami z linux/asm/*.h, ni¿ pisz±c pliki ¼ród³owe w samym assemblerze.
<P>
<P>
<H3>Dostêp do 16-bitowych sterowników z Linux-a/i386</H3>

<P>Taka rzecz jest teoretycznie mo¿liwa
(dowód: zobacz jak DOSEMU mo¿e selektywnie dawaæ dostêp portów do urz±dzeñ programom), i s³ysza³em pog³oskê ¿e kto¶ gdzie¶ ju¿ to zrobi³
(w sterowniku PCI? W dostêpie do VESA ? ISA PnP ? nie wiem).
Je¶li masz wiêcej precyzyjnych informacji na ten temat 
bêda mile widziane.
Jakkolwiek, by uzyskaæ wiêcej informacji dobrymi miejscami s± ¼ród³a j±dra Linuxa,
¼ród³a DOSEMU (i innych programów w 
<A HREF="ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/">DOSEMU repository</A>),
oraz ¼ród³a ró¿nych niskopoziomowych programów dzia³aj±cych pod Linux-em...
(byæ mo¿e GGI je¶li wspiera standard VESA).
<P>Zasadniczo, musisz u¿ywaæ 16-bitowego trybu chronionego lub trybu vm86.
<P>Na pocz±tku jest w miarê prosto to ustawiæ, ale bêdzie to dzia³aæ tylko z dobrze-zrobionym kodem
The first is simpler to setup, but only works with well-behaved code
nie wykorzystuj±cym jakiejkolwiek arytmetyki segmentowej
that won't do any kind of segment arithmetics
lub bezwzglêdnego adresowania segmentu (w szczególno¶ci adresowania segmentu 0),
or absolute segment addressing (particularly addressing segment 0),
do czasu zmian ¿e wszystkie u¿ywane segmenty mog± byæ ustawione w zaawansowany
sposób w LDT.
<P>Pó¼niej pozwala siê na wiêksz± zgodno¶æ z vanilla 16-bitowym otoczeniem (? przyp.t³um.),
ale wymaga to bardziej skomplikowanej manipulacji.
<P>W obu przypadkach, przed wykonaniem skoku do 16-bitowego kodu 
musisz
<UL>
<LI>mmap ka¿dy absolutny adres u¿ywany w 16-bitowym kodzie
(taki jak ROM, bufory video, docelowe DMA, i mapowane-do-pamiêci I/O)
z /dev/mem to przestrzeni adresowej twojego procesu,</LI>
<LI>ustawiæ LDT i/lub monitor trybu vm86.</LI>
<LI>pobraæ w³a¶ciwe prawa dostêpu do I/O z j±dra (patrz powy¿sza sekcja)</LI>
</UL>

I znowu, ostro¿nie czytaj ¼ród³a do rzeczy zawartych
w powy¿szych informacjach o magazynie DOSEMU,
w szczególno¶ci te mini-emulatory
do uruchomiania ELKS i/lub prostych programów .COM pod Linux-em/i386.
<P>
<P>
<H2>5.2 DOS</H2>

<P>Wiêkszo¶æ DOS-owych extenderów zawiera interfejs do us³ug DOS-a.
Poczytaj dokumentacje na ich temat,
ale czêsto, symuluj± one tylko <CODE>int $0x21</CODE> i inne,  
wiêc robisz ``jakby¶'' by³ w trybie rzeczywistym
(mam w±tpliwo¶ci czy nie s± tylko ³±cznikami
i rozszerzaj± rzeczy by pracowa³y z 32-bitowymi operandami;
najczê¶ciej s± tylko przej¶ciem w przerwanie
do trybu rzeczywistego lub przez uchwyt vm86).
<P>Dokumentacja na temat DPMI i inne (oraz znacznie wiêcej) mo¿esz znale¼æ na 
<A HREF="ftp://x2ftp.oulu.fi/pub/msdos/programming/">ftp://x2ftp.oulu.fi/pub/msdos/programming/</A><P>DJGPP przychodzi z w³asn± (ograniczon±) glibc pochodn±/podzestawem/wymienion±, tak¿e.
<P>Jest mo¿liwa cross-kompilacja z Linux-a do DOS-a,
zobacz katalog devel/msdos/ najbli¿szej kopii FTP serwera sunsite.unc.edu
Zobacz tak¿e ekstender-dosa MOSS z projektu Flux w utah.
<P>Inne dokumenty i FAQ s± bardziej skoncentrowane na DOS-ie.
Nie zalecamy rozwoju pod DOS.
<P>
<P>
<H2>5.3 Winwybuchy i takie</H2>

<P>(od t³um. Autor tego dokumentu nie przepada za Windows, s³usznie zreszt±,
i dlatego czê¶æ tej podsekcji nie bêdzie mile widziana przez zwolenników
tego systemu :).
Hej, ten dokument zawiera tylko wolne oprogramowanie.
Zadzwoñ kiedy Winwybuchy stan± siê wolne,
lub gdzie bêd± dostêpne wolne narzêdzia do tego!
<P>No, po tym wszystkim, jest :
<A HREF="http://www.cygnus.com">Cygnus Solutions</A>
rozwijaj±cy bibliotekê cygwin32.dll,
dla programów GNU to uruchomienia pod platformami MakroGówna.
<P>Jakkolwiek, mo¿esz u¿ywaæ GCC, GAS, wszytkich narzêdzi GNU,
i wielu innych Unix-owych aplikacji.
Zerknij na ich stronê domow±.
Ja (Faré) nie zamierzam rozszerzaæ Losedoze (od t³um. Windows -> Windoze -> 
Losedoze (Lose) - przegrywaæ) programowania.
ale jestem pewny ¿e wszêdzie mo¿esz znale¼æ pe³no dokumentów na tem temat...
<P>
<P>
<H2>5.4 Twój w³asny OS</H2>

<P>Kontrola jest tym co przyci±ga wielu programistów do assemblacji,
chc±cych najczê¶ciej rozwijaæ OS co prowadzi lub pochodzi od ³amania w assemblerze.
Zapamiêtaj, ¿e ka¿dy system pozwalaj±cy na samorozwój mo¿e byæ okre¶lony jako "OS"
nawet mimo tego, ¿e mo¿e chodziæ "nad" pracuj±cym systemem z wielozadaniowo¶ci± lub I/O (takim jak Linux na Mach lub OpenGenera na Unix-ie), itd. 
St±d, dla ³atwiejszego usuwania b³êdów,
mo¿esz rozwijaæ twój ``OS'' najpierw jako proces chodz±cy
pod Linux-em (pomimo powolnego dzia³ania), a potem u¿yæ
<A HREF="http://ww.cs.utah.edu/projects/flux/">Flux OS kit</A>
(co daje mo¿liwo¶æ u¿ycia sterowników Linux-a i BSD w twoim w³asnym OS)
by zrobiæ go niezale¿nym.
Gdy twój OS jest stabilny, jest jeszcze czas by napisaæ 
sterowniki je¶li naprawdê to lubisz.
<P>To HOWTO nie zawiera wewn±trz tematów takich jak
kod Boot loadera &amp; wchodzenie w tryb 32-bitowy, 
Zarz±dzanie Przerwaniami,
Podstawy o intelowskim ``trybie chronionym'' lub ``V86/R86'', 
definiowania twoich formatów obiektów i konwencji wywo³añ.
G³ównym miejscem gdzie mo¿esz znale¼æ pochodne informacje o tym wszystkim
to kody ¼ród³owe istniej±cych OS i bootloaderów.
Masa wska¼ników jest na poni¿szej stronie WWW:
<A HREF="http://www.tunes.org/~tunes/doc/Review/OSes.html">http://www.tunes.org/~tunes/doc/Review/OSes.html</A><P>
<P>
<H2><A NAME="s6">6. DO ZROBIENIA &amp; WSKAZANIA</A></H2>

<P>
<P>
<UL>
<LI>wype³niæ niekompletne sekcje</LI>
<LI>dodaæ wiêcej wska¼ników na oprogramowanie i dokumentacjê</LI>
<LI>dodaæ proste przyk³ady z ¿ycia do zilustrowania sk³adni, mocy,
i ograniczeñ proponowanych rozwi±zañ.</LI>
<LI>poprosiæ ludzi o pomoc w tym HOWTO</LI>
<LI>znale¼æ kogo¶ kto ma czas by przej±æ zarz±dzanie tym HOWTO</LI>
<LI>byæ mo¿e napisaæ parê s³ów o assemblacji na innych platformach?
</LI>
<LI>Trochê wskazañ (dodatkowo oprócz tych ju¿ wymienionych w tym HOWTO)
<UL>
<LI>
<A HREF="http://www.intel.com/design/pentium/manuals/">podrêczniki pentium</A></LI>
<LI>
<A HREF="http://www.xs4all.nl/~feldmann">b³êdy cpu w rodzinie x86</A></LI>
<LI>
<A HREF="http://www.eng.ufl.edu/ftp">hornet.eng.ufl.edu dla koderów w assemblerze</A></LI>
<LI>
<A HREF="ftp://ftp.luth.se/pub/msdos/demos/code/">ftp.luth.se</A></LI>
<LI>
<A HREF="ftp://zfja-gate.fuw.edu.pl/cpu/protect.mod">PM FAQ</A></LI>
<LI>
<A HREF="http://www.fys.ruu.nl/~faber/Amain.html">Strona Assemblera 80x86</A></LI>
<LI>
<A HREF="http://www.cit.ac.nz/smac/csware.htm">Courseware</A></LI>
<LI>
<A HREF="http://www.ee.ucl.ac.uk/~phart/gameprog.html">programowanie gier</A></LI>
<LI>
<A HREF="http://bewoner.dma.be/JanW">eksperymenty z programowaniem w linux-ie w tylko-asm</A></LI>
</UL>
</LI>
<LI>I oczywi¶cie, u¿ywaæ twoich zwyk³ych Internetowych Narzêdzi Przeszukiwañ
by znale¼æ wiêcej informacji,
i daæ mi znaæ je¶li znajdziesz co¶ interesuj±cego!</LI>
</UL>
<P>
<P>Author's .sig:
<PRE>
## Faré | VN: Уng-Vû Bân   | Join the TUNES project!  http://www.tunes.org/ ##
## FR: François-René Rideau |    TUNES is a Useful, Not Expedient System     ##
## Reflection&amp;Cybernethics  | Project for a Free Reflective Computing System ##
</PRE>
<P>
<H2><A NAME="s7">7. Od t³umacza</A></H2>

<P> To jest pierwsze t³umaczenie tego HOWTO. Z pewno¶ci± zawiera ono masê b³êdów
i niektóre sentencje mog± mieæ inne znaczenie ni¿ ja im nada³em. Dlatego proszê o email je¶li znajdziesz jakie¶ b³êdy (merytoryczne, gramatyczne i inne). 
Postaram siê poprawiæ dokument w jak najkrótszym czasie i opublikowaæ. 
Uwagi i komentarze ¶lij na 
<A HREF="mailto:wegorz@bydgoszcz.pkobp.pl">Zbigniew Micha³ Kempczyñski</A>. Szczególne podziêkowania sk³adam mojej kole¿ance <EM>Annie Dzieniszewskiej</EM> za pomoc w trudnych gramatycznych kawa³kach tego tekstu.
Je¶li kto¶ wie jak przet³umaczyæ <EM>Legal Blurp</EM> to proszê o email.
<P>
</BODY>
</HTML>