Miałem odpisać na maila, ale widzę wątek, to napiszę tutaj. Może ktoś będzie miał lepszy pomysł.
Zastanowiłem się nad tym i jest w tym trochę racji, żeby udostępnić taką wbudowaną funkcjonalność.
Narzędzia, z którymi się spotkałem zawierają takie makra. Przykłady
- C/C++: http://gcc.gnu.org/onlinedocs/cpp/Stand … acros.html
- NASM: http://www.nasm.us/xdoc/2.11/html/nasmd … ction-4.12
- Coś podobnego ma nawet Free Pascal: http://www.freepascal.org/docs-html/prog/progap7.html
Pewnie wiele innych też.
Zaproponowane przez Ciebie rozwiązanie ma taki problem, że nie jest przenośne: nie jestem w stanie zrobić projektu, w którym będę wstawiał np. datę assemblacji tak, aby każdy mógł to skompilować na dowolnym systemie. Musiałbym pisać osobny zestaw skryptów dla Windowsa i dla Linuksa.
Nie wiem ile w tym jest sensu, ale przyszło mi do głowy pewne generyczne rozwiązanie: pseudorozkaz GEN("description"), który pełniłby rolę uniwersalnego generatora zastępującego swoje ciało wygenerowanym napisem na podstawie podanego opisu. Można byłoby dla pełności zaimplementować w nim część istniejących pseudorozkazów:
gen("rnd(0,33,256)") ;losowa liczba
gen('date("F j, Y, g:i a")') ;data, np. formatowana jak w PHP: March 10, 2001, 5:16 pm
gen("line") ;aktualny numer assemblowanego wiersza
gen("count") ;kolejna liczba zwiększana o jeden przy następnym wywołaniu
Idąc za ciosem można byłoby dodać drugi pseudorozkaz, który nawet przydałby się mi: SYS("command", [args...]), który odpalałby nowy proces o podanej nazwie i wstawiał w miejsce swojego ciała zawartość zwróconego standardowego wyjścia:
.he sys("SuperTableGenerator", 42)
Rezultat: wynik jakiegoś programu generującego super tablice ("SuperTableGenerator.exe") jako ciąg wartości szesnastkowych przyjmującego jeden argument.
Oczywiście "sys" byłby zależny od systemu, ale stanowiłby niezłą furtkę dla prostego generowanie zawartości. Ja często piszę skrypty w ruby, które generują mi jakieś dane, tylko teraz generuję plik binarny, któremu robię "ins", a tu można byłoby generować dane wprost.
W przypadku wielu przebiegów można byłoby cachować wartości wygenerowane przy pierwszym przebiegu.