Можно и так ) Но тут кешируем настоящую функцию. Если задействовано I/O (пусть и с монадой) и закешированные значения могут устаревать, лениво "вычислить" всё сразу не получится.
NASM удобнее если действительно надо скомпилировать и получить готовый объектник. Если нужен hex для одной или нескольких инструкций, чтобы посмотреть глазами или вставить как константу в сишный код, придётся ещё какой нибудь objdump вызывать. В этом плане llvm-mc проще - дали инструкцию, получили hex.
Лучше всё таки привыкать к современным инструментам - тот же llvm-mc периодически использую для всяких мелочей. Дальше уже эти байтики запихиваем в программе в массивчик, даём права и исполняем.
У меня вопрос не про отображение, а про само файловое API. Для влезающих в UCS-2 символов оно регистронезависимое - нельзя создать в одном каталоге a.txt и A.txt Вопрос, работает ли это в общем случае (например, для древневенгерского).
PS Проверил, создаются два файла с именами 𐳀.txt и 𐲀.txt, так что явной поддержки UTF-16 нет.
Самое интересное - это как реально работает динамическая загрузка и вытеснение/подгрузка сегментов для NE (с учётом того, что оно поддерживалось и в реальном режиме Win 3.0 на 8086). Помню, это частично разбиралось в статьях в первых номерах русскоязычного PC Magazine в начале 90х.
То есть XFCE и т.п. таки с приемлемой производительностью не взлетели?
В нативе, конечно, никаких проблем не будет. Просто я слова
воспринял в первую очередь как эмуляцию NES, SNES, всяческих SEGA и прочего.
А так как бюджетный (надеюсь) девайс для "поиграться с RISC-V" выглядит интересно.
Всё таки 32 не 310.
А почему именно telnet а не nc?
Маловато будет. В GB300 MIPS процессор с частотой около гигагерца, и то при эмуляции SNES и т.п. лаги вылезают.
Ну и в цене вопрос, та же GB300 на Озоне в районе 1000р.
Какой такой CISC/RISC в 80486? С Pentium Pro не перепутали?
А ещё были 80860, 80960 и мегамонстр iapx432. Интел много во что игрался )
А в TC нормальную консольку по Control-O завезли?
Почему именно Unix? Я в основном виндовый использую.
Можно и так ) Но тут кешируем настоящую функцию. Если задействовано I/O (пусть и с монадой) и закешированные значения могут устаревать, лениво "вычислить" всё сразу не получится.
NASM удобнее если действительно надо скомпилировать и получить готовый объектник. Если нужен hex для одной или нескольких инструкций, чтобы посмотреть глазами или вставить как константу в сишный код, придётся ещё какой нибудь objdump вызывать. В этом плане llvm-mc проще - дали инструкцию, получили hex.
Лучше всё таки привыкать к современным инструментам - тот же llvm-mc периодически использую для всяких мелочей. Дальше уже эти байтики запихиваем в программе в массивчик, даём права и исполняем.
Есть более современные способы быстро получить байтики для инструкций, хотя бы llvm-mc.
Мемоизация в чистом ФП должна включать явную передачу кеша (можно упростить теми же монадами).
Времена Katmai и Willamette не такие уж давние )
Я проверял на Windows 11, она вышла после добавления древневенгерского (Unicode 8.0, 2015).
У меня вопрос не про отображение, а про само файловое API. Для влезающих в UCS-2 символов оно регистронезависимое - нельзя создать в одном каталоге a.txt и A.txt Вопрос, работает ли это в общем случае (например, для древневенгерского).
PS Проверил, создаются два файла с именами 𐳀.txt и 𐲀.txt, так что явной поддержки UTF-16 нет.
Самое интересное - это как реально работает динамическая загрузка и вытеснение/подгрузка сегментов для NE (с учётом того, что оно поддерживалось и в реальном режиме Win 3.0 на 8086). Помню, это частично разбиралось в статьях в первых номерах русскоязычного PC Magazine в начале 90х.
В первую очередь это про отсутствие побочных эффектов и функции как полноценные объекты языка.
Я имею в виду эмуляцию системных вещей (пространства имён для файловой системы и uid), а не инструкций процессора.