mayton2019

Я отметил совет Нестерова как решение. Но добавлю.

Тебе нужно подойти к преподавателю и задать ему макимальное число вопросов
по поводу того что он хочет на самом деле видеть. Желательно сузить постановку
до такого уровня чтоб ты успела за семестр это сделать. Например делать
транслятор сразу без файлов и сетевого I/O. Пускай это будет просто REPL
консоль как в ранних версиях Haskell.

Есть софистические языки наподобие Brainfuck и Нормальных алгоритмов Маркова.
Они тоже являются языками но скорее экспериментом доведенным до крайности
чем практически полезным. Их можно реализовать за пару дней на любой другом
императивном языке.

Разработка Форт-подобного языка мне тоже кажется набиолее выгодной с точки
зрения цена/производительность но Форт это достаточно нишевый язык и препод
может быть недоволен. Возможно он хотел какие-то более развитые грамматики
а не токько words and spacers.

Можно разработать простейший Лисп но я не уверен что тут в семестр уложишся. Тем
более что у тебя только базовый уровень всего остального. Но Лисп транслятор
на минималках был бы самой красивой курсовой работой на потоке.

У меня есть идея, создать свой диалект ассемблера с простым синтаксисом, что бы на нем мог программировать любой человек, не проигрывая в скорости.

Это очень наивная идея. Она была работоспособной в XX веке, когда система команд была простая и процессоры
были однопоточные и без кешей и конвейеров и микро-кода (КР580, Z80...)

Современный компиллятор знает больше чем обычный человек-разработчик. И очень мало людей в мире
в состоянии писать машинный код думая одновременно
1) О состоянии кешей
2) О состоянии всех регистров
3) О микрокоде и о загрузке конвейеров
4) Об таймингах mmx, sse, avr командах и сравнивать их на ходу по скорости исполнения
5) О прогнозировании переходов

Современный компиллятор - видит глубоко и знает очень много. И очень сомнительно что
человек, а тем более пишуший на новом языке да еще и в каких-то кодах может хоть
близко подойти к этому пределу. Разумеется мы можем рассмотреть частные случаи
когда человех перехитрил компиллятор, но промышленная разработка не состоит
из таких кейсов.

Обычный кейс - надо писать код.
Надо писать МНОГО кода.
Надо не делать ошибок.
Надо гарантировать хорошую производительность этого кода.

Такая грамматика уже создана. Называется язык Prolog.

Сразу скажу что сама затея создания словесных экспертных систем обречена на провал.
Растущая комбинаторная сложность и сложность задавания вопросов этой системе
свела на нет все усилия лет 30 назад.

Сегодня такие системы считаются legacy, и языковые модели-чаты их полностью заметили.
Потому что обучить модель легче чем человеку описать сет рулов. И еще все это потом протестировать.

Конвейер компилляции С++ точно не прост. На хай-левеле это 3 шага. Препроцессор, компилляция и линкер.
А сама компилляция в свою очередь тоже сложна. Там полюбому будет работа с шаблонным процессором
и еще будет обязательно проход оптимизации. Это когда из кода можно выкинуть недостижимые ветки или
размотать циклы. И это тоже шаг.

Как Jit Компиляторы обнаружат недостижимой код и лишние проверки?

Если мне не изменяет память, JIT компиллятор компилирует java-метод целиком. Переводя byte-code в машинный код для x86 например.

А то что спрашивает автор - это задача основного компиллятора который язык Java переводит в байткод.

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

ли Космические Лучи, в Ram попали, что тогда будет?

Программисты 20-го века работали в условиях глючной памяти (когда были ЭВМ на лампах и на тразнисторах)
и обрабатывали специальное прерывание типа "глюк в ячейке памяти".

С точки зрения современной парадигмы разработки - это невозможно. Никакой прикладной
программист не ставит себе задачу отслеживания целостности памяти. Это как-бы не его
уровень. Мы предполагаем что память надежна и всегда корректна. А иначе ОС выпадает
в синий экран и никаких принятий решения мы все равно не сделаем а облачные балансировщики
примут свои решения когда хост выпадет из сети.

В современной ОС также по дефолту считается что никакой хакер никогда не меняет
память вашего процесса. Это - основа безопасности ОС и если хакер все таки что-то может
менять - то это плохая ОС и плохая безопасность и надо что-то решать на уровне системной
архитектуры и тем более прикладной программист здесь ничего не сможет сделать.

Рассматривать такие случаи в топике Java - бесполезно и контр-продуктивно. Давайте
их рассматривать в топиках инфо-беза и операционок.