/usr/share/doc/HOWTO/pl-html/Assembly-HOWTO.pl.html is in doc-linux-pl-html 2002.06.14-2.
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 © 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 <fare@tunes.org>
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&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&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&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&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(".code16\n")</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 $<
</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) < $< > $@
</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>-></CODE>asm zmieniaj±c nazwê
przez wstawienie wyra¿eñ takich jak to
<HR>
<PRE>
void foo asm("bar") (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 & 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 & 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&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>
|