odwoływać się bezpośrednio do rejestrów i urządzeń I/O

kontrolowć zachowania kodu w sekcjach krytycznych, które normalnie powodują blokady między rożnymi wątkami lub urządzeniami

optymalizować kod generowany przez kompilator

łączyć ze sobą niekompatybilne fragmenty kodu (np. generowane przez różne kompilatory) poprzez stworzenie dla nich niskopoziomowego interfejsu

wykorzystywać własności i funkcje specyficzne dla naszego procesora

stworzyć kod zoptymalizowany dla naszego sprzętu. Należy jednak pamiętać, że nie będzie on się zachowywał równie efektywnie na innej maszynie

w ogólności - mamy pełną kontrolę nad swoim kodem

pisanie jest początkowo długie i nużące

kod jest trudny do zrozumienia i modyfikowania (m.in. do rozwijania i konserwowania)

kod jest bardzo podatny na błędy

błedy są bardzo trudne do zlokalizowania

rezultaty naszej pracy są nieprzenaszalne na inną architekturę

stworzony kod będzie zoptymalizowany tylko dla ustalonej implementacji na takiej samej architekturze (np. programując dla architektury 486 nie wykorzystamy, mając nowy procesor, obecności rozkazów MMX, 3DNOW, itp.)

koncentrujemy się na pisaniu drobiazgów, a nie na projektowaniu algorymów, które mogą zdecydowanie bardziej usprawnić działanie naszego programu (np. możemy spędzić niepotrzebnie mnóstwo czasu implementując prostą listę, podczas gdy zdecydowanie większe usprawnienie przyniosłoby np. wprowadzenie tablicy haszującej)

małe zmiany w algorytmie mogą całkowicie zdezaktualizować kod. Jesteśmy więc zmuszeni do napisania wszystkiego od nowa, albo do pogodzenia się z już isniejącym rozwiązaniem.

ograniczamy fragmenty kodu asemblera do mimimum

otaczamy te fragmenty dobrze zdefiniowanym interfejsem

staramy się nie pisać tych fragmentów ręcznie, tylko edytować to co zostanie wygenerowane na podstawie kodu zapisanego w języku wyższego poziomu (np. można do tego użyć kompilatora gcc)