Odpověď na názor

A este dodatok... toto je napr. ukazka zo zdrojakov najnovsieho SBCL (konkretne alloc.lisp):

<code>
#+sb-assembling ; We don't want a vop for this one.
(define-assembly-routine
(move-from-signed)
((:temp eax unsigned-reg eax-offset)
(:temp ebx unsigned-reg ebx-offset))
(inst mov ebx eax)
(inst shl ebx 1)
(inst jmp :o BIGNUM)
(inst shl ebx 1)
(inst jmp :o BIGNUM)
(inst shl ebx 1)
(inst jmp :o BIGNUM)
(inst ret)
BIGNUM

(with-fixed-allocation (ebx bignum-widetag (+ bignum-digits-offset 1))
(storew eax ebx bignum-digits-offset other-pointer-lowtag))

(inst ret))
</code>

Preco by som sa ja mal zaoberat niecim, na com pracuje "banda" programatorov, ktori rozumeju assembleru omnoho viac ako ja, a davaju mi jazyk ktory mi dovoli riesit ine, a pre moju ulohu podstatnejsie problemy (naozaj vyrazovo silny jazyk)? Naco programovat 100x programovane? Oni nad optimalizaciou kompilatora a vysledneho asm kodu pracuju niekolko rokov. Mysliet si, ze ja urobim velky a zlozity projekt v asm optimalnejsie, je uplna zhovadilost (a vobec by mi nepomohlo studovat teraz roky a roky assembler, aj ked z neho samozrejme nieco malo viem - hlavne 8051, 8086...). Ako tu bolo naznacene - zmeni sa procesor a moje pidi optimalizacie su nanic. Ak niekto nechape zmysel abstrakcia, tak s tym ja uz asi nic nenarobim...