Sikor, żeby zrozumieć, skąd się wzięły nieudokumentowane rozkazy, dlaczego się pojawiły, czemu niektóre są tzw. stabilne a niektóre nie (co jest samo w sobie abstrakcją bo zależy od arbitralnych założeń, jeśli weźmiemy pod uwagę wszystkie procesory 8-bitowych Atari, od 400 do 130XE, to nie ma stabilnych, a przynajmniej ich ilość mocno się zmniejsza) i dlaczego wg producenta nie należy ich używać, musiałbyś zrozumieć, jak działa dekoder rozkazów i jak się go projektuje i co to są automaty formalne. Oraz dodatkowo - jak w dużej firmie wygląda zarządzanie takim projektem oraz strategią rozwoju i jakie etapy przechodzi. Część z nich to były propozycje projektanta, które nie zostały zaakceptowane ze względu na to, że kody były potrzebne na już planowane wersje rozwojowe, a uznano, że można zamiast nich wstawić coś bardziej użytecznego - to strategia. Duża część z nich powstała przypadkowo - otóż projektując automat formalny będący podstawą przyszłego dekodera rozkazów uwzględnia się zaplanowane stany i przejścia między nimi. Następnie następuje upraszczanie automatów poprzez wiązanie przejść stanów w ciągi, z których jedne stanowią część drugich. Jest to etap konieczny, gdyż od uproszczenia automatu zależy potem ilość bramek w wyprodukowanym scalaku a to się przelicza już bezpośrednio na koszt jego produkcji. I na tym etapie dba się tylko i wyłącznie o to co zostało zaplanowane - to ma funkcjonować zgodnie ze specyfikacją. Na skutek tego procesu mogą się pojawić - i pojawiają się - sekwencje dodatkowe, nie przewidziane w projekcie, będące efektem pętli, albo nowych ciągów stanów. Nikomu to nie przeszkadza, ważne jest jedynie aby te przewidziane działały zgodnie z planem. I tak powstają nowe instrukcje. A dlaczego nie należy ich używać? Bo w następnej rozwojowej wersji procesora, projektant zaprojektuje dekoder i jego automat stanów od zera. A ponieważ pojawią się rzeczy nowe, upraszczanie automatu również będzie przeprowadzone na nowo i nie ma gwarancji, że to co przypadkowo powstało poprzednio się powtórzy. Albo inaczej - jest wysokie prawdopodobieństwo, że nie. W związku z tym, ktoś kto by napisał program na 8086 korzystając z instrukcji niepublikowanych (a na pewno takie są, tylko być może nikt się nimi nie zajmował, bo wiedział że to bez sensu) już za rok mógłby go wyrzucić do śmieci, bo wszyscy wymienią procesor na 286 i program nie pójdzie.
W Atari nikt procesora nie wymieniał bo został spisany na straty po przekształceniu Atari Inc. w Atari Corp. - ok, ktoś to jeszcze kupuje, damy nową obudowę, wytniemy rozwojowe złącze, będzie taniej ale to tyle - rozwijamy ST. I dlatego właśnie było 20 lat czasu, żeby jakiś pasjonat zbadał i wbudował te niepublikowane instrukcje w swój assembler - bez tego nikt by nawet o tym nie wiedział.
Ostatnio edytowany przez wieczor (2014-01-21 23:44:10)
The problem is not the problem; the problem is your attitude about the problem
