Есть моя реализация в программируемой логике микропрограммируемого автомата ( по сути дела простой контроллер (процессор)), с широким командным словом. Для удобства программирования данной забавы за неделю был написан ассемблер.
На текущий момент есть команды 5 типов (мнемоники и перестановки бит в командном слове я могу менять как угодно):
1. Sw, NOP  - без операнда
2. jmp int, Wh int - с непосредственным значением (16 бит)
3. begz Rx;  bnegz Rx;  br Rx; Save Rx - с параметром (номер регистра)
4. Li Rx, int - с номером регистра и непосредственным значением
4. and Rdst,Rx,Ry; or Rdst,Rx,Ry; xor Rdst,Rx,Ry; rlc Rdst,Rx,Ry; mul Rdst,Rx,Ry и т.д. - с номерами 2 регистров источников и регистра приемника.
Где int - целое бесзнаковое (16 - 33!) бит значение, Rx,Ry,Rdst - номер регистра (0-15).
Также должна быть команда задания генератора адреса сборки .ORG int (те установка стартового адреса).
Одновременно могут исполняться несколько команд:  rlc Rdst,Rx,Ry; Sw; Wh 0x210 (циклический сдвиг влево, выгрузка в порт вывода, все это в аппаратном цикле 0x210 раз).

Как происходит компиляция сейчас:
1 - читаю файл исходного текста *.asm по строкам, в цикле перебора массива строки убираю пробелы если их более 2, перевожу все символы в нижний регистр, продолжение строки с символом коментария # или // - отсекаю. Каждую полученую строку нумерую, бью на лексемы, сравниваю каждую лексему с мнемоникой возможных команд и для каждой распознанной команды отдельно проверяю синтаксис и считываю параметры, накладываю маску на командное слово. После чего строку с адресом (счетчик с начальным значением из ORG) и командным словом выгружаю в файл xxx.lst.
2 - читаю *.lst и убераю пустые строки с редакцией поля адреса и пишу в *.tmp, все метки с адресом скидываю в файл *.xref
к примеру:
210: 
220: label700:
230 rlc Rdst,Rx,Ry; Sw; Wh 0x210  *command_word
преобразую в:
210 rlc Rdst,Rx,Ry; Sw; Wh 0x210 *command_word
где * - метка начала командного слова, и в *.xref файле добавляется запись 210 : label700
3 - читаю *.tmp  и ищу команду JMP и по ее параметру (к примеру label700) ищу значение в *.xref файле, подменяю в командном слове значение перехода, пишу строку в выходной *.bin файл в виде address:command_word.

Я к сожалению программист из HDL и embedded мира и искусством писать под WIN не обладаю и С/C++ как таковой не знаю.  Но мое детище расширяется и ассемблер должен быть параметаризован, те иметь возможность редакции системы команд. Я хочу сделать настройку программы из файла списка команд и описания модифицируемых полей командного слова.

Насколько я понимаю чтоб красиво это сделать надо смотреть в сторону шаблонов STL, контейнера  multimap и типа String ?
Может кто то уже делал или видел подобное и поделится исходниками или ссылкой на проект лексического анализа текста? 

 

Хорошее решение ... для 70х годов прошлого века   Тогда компьютеры были большие, а память в них маленькая. Сегодня памяти в них достаточно, что бы не делать костыли в виде промежуточных файлов. Всю структуру по мере разбора можно накапливать в памяти.

Для начала несколько вопросов -

•  Предполагается ли раздельная трансляция (т.е. компиляция в .obj и сборка из них выходного файла)?
•  Предполагается ли адресная арифметика?
•  Допускается ли в адресной арифметике ссылки вперед, и на сколько уровней?
•  Должен ли быть ассемблер 'вещью в себе', или предполагается что то большее голого ассемблера?

Вообще то классическая схема посторения ассемблера это 2х проходная генерация. (Обы прохода выполняются одной и той же процедурой, но режим работы разный)
На первом проходе реальный код не генерируется, но производится подсчет размера (т.е. адресов). На этом проходе собираются реальные значения всех меток.
На втором проходе генерируется код. При этом используются значения меток, полученных на первом проходе.

Ой ой ой. Это не совсем простая задача даже для тех, кто владеет С++   Советую почитать умные книжки, в первую очередь - 'Книгу дракона' (Ахо, Ульман. Компиляторы. Принципы, технологии и инструментарий)

Раздельная трансляция не нужна.
Адресная арифметика возможна в будующем.
Требуется голый расширяемый ассемблер, да и когда 10 лет пишешь на asm, больше ничего не нужно.

Количество проходов компилятора тоже не сильно актуально, тк опыт показывает что МПА эффективен при небольшом количестве состояний (до 2к реально 50-300) если больше - то надо пользовать готовые решения типа NIOS или внешнего процессора. То что я сделал - компилирует за  3 прохода.
За ссылку спасибо, буду искать. 


Да, с кучей файлов это я конечно погорячился. Это моя вторая в жизни программа под WIN.  
Как происходит выделение памяти при NEW или в шаблонах STL при запросе большем чем есть в RAM, те OS разгрузит свап файл и предоставит память или сгенерирует исключение которое надо ловить?
А какие есть в С++ (MS VS2008) возможности нечеткого поиска?

Если памяти ты пытаешься выделить больше, чем доступно ОС с учетом файла подкачки, то будет сгенерировано исключение... Хотя, например, Linux имеет оптимистичный менеджер памяти, который всегда память выделяет... Короче, умные люди говорят, что программа, обычно, не доживает до того момента, когда будет сгенерировано исключение, так как юзер ее убьет (или через task manager, или через RESET).

Подозреваю, что таких стандартных средств нет. Но можешь воспользоваться этим.

В таком случае можно ограничится однопроходным ассемблером. 
В процессе разбора текста сразу генерируется бинарное представление, а для частей представления, зависимых от адресов (меток) создаются patch записи (в памяти). Эти записи состоят из троек <метка,адрес в бинарном представлении,формат patchа>. Так же создается таблица символов. По окончании парсинга все patch записи обрабатываются (реальные данные пишутся в бинарное представление)

Для простой настройки ассемблера на целевой процессор можно предусмотреть таблицы с мнемониками и форматами команд. Таблицы задаются в виде массива структур