The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Обновление операционной системы MenuetOS 1.50, написанной на ассемблере , opennews (??), 02-Мрт-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


2. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +5 +/–
Сообщение от Аноним (2), 02-Мрт-24, 12:38 
Писать на ассемблере и писать лучше компилятора си на ассемблере это разные вещи. Опять же, свой сишный код ты запустишь на телефоне, а ассемблерный нет, так что не расстраивайся особо, ты просто опоздал родиться. Во времена доса это было проще.
Ответить | Правка | Наверх | Cообщить модератору

29. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от Аноним (29), 02-Мрт-24, 13:37 
Чтобы компилятор си умел писать лучше чем программист на ассемблере, нужно уметь его этому научить, то есть знать как правильно писать на ассемблере. А если уже знаешь как правильно писать на ассемблере и имеешь цель написания оси на асме, то компилятор си превращается в лишнюю сущность.

К тому же си добавляет ундефинид бихаваёров, а всякие расты -- нечитаемой тяжести. Тут ж ось для умеющих на программирование, а не фпродакшонцов.

Ответить | Правка | Наверх | Cообщить модератору

32. "Обновление операционной системы MenuetOS 1.50, написанной на..."  –7 +/–
Сообщение от Аноним (32), 02-Мрт-24, 13:45 
Какой бред, вам это кто рассказал, где вы эту жость вычитали? Оптимизировать должен компьютер, это его задача. А чтобы UB не было - ну так надо правильные языки брать, где его нет by design.
Ответить | Правка | Наверх | Cообщить модератору

42. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +9 +/–
Сообщение от Аноним (42), 02-Мрт-24, 14:21 
Вас жестоко обманули, задача компьютера выполнять действия, а думать, в том числе над оптимизациями, должен программист.
Ответить | Правка | Наверх | Cообщить модератору

66. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от Аноним (66), 02-Мрт-24, 16:41 
> а думать, в том числе над оптимизациями, должен программист.

приведите пример кода на сях, который вы можете оптимизировать на асме лучше, чем какойнить gcc или llvm (без отключенных оптимизаций, ессно).

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

Ответить | Правка | Наверх | Cообщить модератору

145. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от k200v3 (?), 03-Мрт-24, 11:00 
libjpegturbo гляньте например. Опять же иногда при приходится даже в машинных кодах писать и делать кусок памяти executable, ибо внезапно msvc не умеет naked функции для x64...
Ответить | Правка | Наверх | Cообщить модератору

156. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от ng (ok), 03-Мрт-24, 12:36 
> приведите пример кода на сях, который вы можете оптимизировать на асме лучше, чем какойнить gcc или llvm

Компиляторы без оптимизации добавляют лишние команды ASM, сжирающие процессорное время без изменения результата. Например, битовое расширение 8->16->32 без надобности.

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

Многократно зафиксировано на тулчейне микроконтроллеров.


Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

83. "Обновление операционной системы MenuetOS 1.50, написанной на..."  –1 +/–
Сообщение от Аноним (83), 02-Мрт-24, 18:07 
Вам во времена перфокарт, да не фортрановские, а когда машинный код напрямую вводили.
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

89. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от Аноним (89), 02-Мрт-24, 18:45 
У вас ещё неоптимизирующий компилятор? Тогда мы идём к вам!
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

139. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +1 +/–
Сообщение от Прохожий (??), 03-Мрт-24, 07:43 
Программист нужен только до тех пор, пока компьютер глуп и не понимает естественный язык (а ещё лучше, мысли) человека. В каком-то уже не таком отдалённом будущем программисты станут лишними.
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

205. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от Серб (ok), 04-Мрт-24, 16:29 
И вместо программ будет нечто, выдающее решения "похожие на правду".

Примерно так же, что программист будет не нужен, говорили при появлении SCADA.

А потом выяснилось, что работы для обеспечения возможностей SCADA в разы больше. И нужны они только для того, что бы неспециалисты не имея четких критериев, что то могли делать.

Ответить | Правка | Наверх | Cообщить модератору

162. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от Аноним (162), 03-Мрт-24, 13:36 
Вот почему пользователями и используются вида и линуксах иногда. Потому что разработчики минуэтос думают, как оптимизировать, а остальные просто клепают нюто, на что есть спрос сейчас, оставляя всё остальное на откуп компилятора.
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

43. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +4 +/–
Сообщение от Аноним (43), 02-Мрт-24, 14:22 
>Тут ж ось для умеющих на программирование, а не фпродакшонцов.

Программирование - это не дворды из регистра в регистр перекладывать.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

47. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +2 +/–
Сообщение от Аноним (2), 02-Мрт-24, 14:54 
В том и дело, что компилятор этому учат под каждое поколение процессоров, каждые несколько лет. И если посмотреть на применяемые оптимизации, легко понять, что человек с таким не справится никогда. Ассемблер был популярен, когда компилятор ещё не умел эффективно оптимизировать код. Это ещё не говоря про PGO. А SIMD оперировать никто не запрещает -- компиляторы самостоятельно могут только достаточно примитивные оптимизации применять.
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

52. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +2 +/–
Сообщение от Аноним (83), 02-Мрт-24, 15:10 
> А если уже знаешь как правильно писать на ассемблере и имеешь цель написания оси на асме, то компилятор си превращается в лишнюю сущность.

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

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

146. "Обновление операционной системы MenuetOS 1.50, написанной на..."  –1 +/–
Сообщение от Аноним (146), 03-Мрт-24, 11:06 
В пещерах сыро и холодно, там вряд ли жили также как и сейчас не живут в погребах. Просто наскальная живопись и останки лучше сохранялись в пещерах, вот и пошли "пещерные люди"
Ответить | Правка | Наверх | Cообщить модератору

53. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +1 +/–
Сообщение от n00by (ok), 02-Мрт-24, 15:11 
> Чтобы компилятор си умел писать лучше чем программист на ассемблере, нужно уметь
> его этому научить, то есть знать как правильно писать на ассемблере.

Знаете? Расскажете, что делается ниже?

Сравнительный анализ perf stat до и после модификации:

Performance counter stats for ***:

    25 825 846 646      cycles:u                  # 2259676,844 GHz
    12 440 035 801      instructions:u            #    0,48  insn per cycle
     3 120 008 855      branches:u                # 272990537,667 M/sec
     1 039 998 618      branch-misses:u           #   33,33% of all branches

     9 581 647 564      cycles:u                  # 2254505,309 GHz
    11 600 026 289      instructions:u            #    1,21  insn per cycle
     2 280 005 786      branches:u                # 536471949,647 M/sec
        80 002 443      branch-misses:u           #    3,51% of all branches
...

--- a/interp.asm
+++ b/interp.asm
    mov    eax, [opcode]
    shl    rax, instruction_size_log2
+;    Переход никогда не происходит. *********
+;    ***************************************
+    jc    .stop
    lea    rax, [rax + vm_base + vm_base_lbl - execute_instruction]
    next_opcode
    jmp    rax
-    ud2
+.stop:    ud2




Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

59. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +3 +/–
Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 15:32 
вы забыли приложить документацию по асм хрен пойми какого цпу и его даташит
Ответить | Правка | Наверх | Cообщить модератору

97. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +1 +/–
Сообщение от n00by (ok), 02-Мрт-24, 19:41 
Такой процессор "по умолчанию" тут у каждого, такой же как и у ОС в обсуждаемой теме. А даташиты у всех экспертов конечно же и так есть.
Ответить | Правка | Наверх | Cообщить модератору

105. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 21:05 
> у всех экспертов конечно же и так есть.

ну тогда надо подчеркнуть экспертов-телепатов, я просто не из таких :)

Ответить | Правка | Наверх | Cообщить модератору

112. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от n00by (ok), 02-Мрт-24, 21:52 
Так я конкретного эксперта спрашивал. Он так и не смог ответить. Наверное, занят, учит компилятор компилировать.)
Ответить | Правка | Наверх | Cообщить модератору

81. "Обновление операционной системы MenuetOS 1.50, написанной на..."  –1 +/–
Сообщение от Аноним (81), 02-Мрт-24, 18:02 
Пример конечно занятный и зачетный, но скорее он не про умение в ассемблер, а про кучу штеудовских костылей и спекулятивных подпорок в x86.
И даже как-бы получается что знание оттенков вкуса этого гуана становиться "экспертизой".

Ну и особо примечательно что все эти-же костыли сейчас активно пропагандируются как "сильные стороны и преимущества" RISC-V ;)

Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

84. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от Аноним (83), 02-Мрт-24, 18:08 
Ассемблер вне привязки к архитектуре не существует.
Это вы ещё ARM-овских костылей не видели.
Ответить | Правка | Наверх | Cообщить модератору

87. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +1 +/–
Сообщение от Аноним (81), 02-Мрт-24, 18:27 
Не, я про другое.

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

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

Ответить | Правка | Наверх | Cообщить модератору

88. "Обновление операционной системы MenuetOS 1.50, написанной на..."  –1 +/–
Сообщение от Аноним (89), 02-Мрт-24, 18:43 
Эльбрус-брелоки лучше стеклянных бус, ага.
Ответить | Правка | Наверх | Cообщить модератору

95. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +1 +/–
Сообщение от Аноним (81), 02-Мрт-24, 19:35 
Индейцы и папуасы всегда предпочитали бусы.
Как минимум, пока не стало слишком поздно.
Это исторический факт, с которым сложно спорить.

Как-то уже давно было сформулировано - каждому свое, но индейцев мне всё-равно жалко.

Ответить | Правка | Наверх | Cообщить модератору

106. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от n00by (ok), 02-Мрт-24, 21:08 
Особенно жалко племя Сиу, которое некий якобы писатель оклеветал в "Последнем из могикан".
Ответить | Правка | Наверх | Cообщить модератору

98. "Обновление операционной системы MenuetOS 1.50, написанной на..."  –2 +/–
Сообщение от n00by (ok), 02-Мрт-24, 19:51 
> Пример конечно занятный и зачетный, но скорее он не про умение в ассемблер

Действительно, понять, что делает патч можно по выдаче perf stat и без знания ассемблера.

Ответа, что примечательно, нет.

> И даже как-бы получается что знание оттенков вкуса этого гуана становиться "экспертизой".

Я верно понимаю, отвечает тот же эксперт, что писал в #29 вот это:

>>> А если уже знаешь как правильно писать на ассемблере

Так то оно рядом замечательно смотрится. ;)

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

104. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +1 +/–
Сообщение от Аноним (81), 02-Мрт-24, 21:02 
> Действительно, понять, что делает патч можно по выдаче perf stat и без знания ассемблера.
> Ответа, что примечательно, нет.

Патч добавляет несколько строк и исходнику - с такой формулировкой поспорить сложно.
Зачем он это делает и как интерпретировать изменение в счетчиках - тут уже могут быть разночтения.

Очевидно что добавление инструкции перехода, который никогда не выполняется, увеличивает % верных предсказаний.
Это увеличение branch-hit приводит к тому, что предсказатель считает контекст истории переходов связанный с этим фрагментов ценным и сохраняет его дольше, а также пытается реже выкидывать из uos-cache целевые адреса косвенного перехода.
Соответственно, могут быть условия (особенно на синтетических тестах), когда такая "оптимизация" в целом работает в плюс.
Но на другой модели ЦПУ и/или на другом коде/данных, как правило все подобные плюсы становятся отрицательным.

> Я верно понимаю, отвечает тот же эксперт, что писал в #29 вот это:

Нет.


--

На всякий уточню - меня расстраивает, что за подобное "штопанье чужих носков" мне не только платят деньги, но и настойчиво хотят сделать это "еще более", вместо того чтобы хотя-бы теже деньги вложить в разработку чего-то собственного (но не в полировку даренных стеклянных бус в виде RISC-V).

Ответить | Правка | Наверх | Cообщить модератору

109. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от n00by (ok), 02-Мрт-24, 21:47 
>> Я верно понимаю, отвечает тот же эксперт, что писал в #29 вот это:
> Нет.

Жаль, эксперимент провалился. #29, #42 и #90 писал точно один, эксплуатируя нумератор Анонимов сайта.

Впрочем, 90 написано позже 81, значит ответить он не смог.

>> Действительно, понять, что делает патч можно по выдаче perf stat и без знания ассемблера.
>> Ответа, что примечательно, нет.
> Патч добавляет несколько строк и исходнику - с такой формулировкой поспорить сложно.
> Зачем он это делает и как интерпретировать изменение в счетчиках - тут
> уже могут быть разночтения.
> Очевидно что добавление инструкции перехода, который никогда не выполняется, увеличивает
> % верных предсказаний.

То есть патч увеличивает % верных предсказаний. Это очевидно из чисел в выдаче perf рядом с %. Это мог бы любой ответить, а значит и тот эксперт тем более.

С инструкцией как раз не очевидно и требует знаний, например сходу я не нашёл в Optimization Manual подходящего правила.

> Это увеличение branch-hit приводит к тому, что предсказатель считает контекст истории переходов
> связанный с этим фрагментов ценным и сохраняет его дольше, а также
> пытается реже выкидывать из uos-cache целевые адреса косвенного перехода.
> Соответственно, могут быть условия (особенно на синтетических тестах), когда такая "оптимизация"
> в целом работает в плюс.
> Но на другой модели ЦПУ и/или на другом коде/данных, как правило все
> подобные плюсы становятся отрицательным.

+;    Переход никогда не происходит. Предотвращает предсказания следующего
+;    косвенного перехода, во многих случаях некорректные.

> --
> На всякий уточню - меня расстраивает, что за подобное "штопанье чужих носков"
> мне не только платят деньги, но и настойчиво хотят сделать это
> "еще более", вместо того чтобы хотя-бы теже деньги вложить в разработку
> чего-то собственного (но не в полировку даренных стеклянных бус в виде
> RISC-V).

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

В данном случае пришлось штопать свои носки, когда оптимизированный код на асме без той инструкции позорно проиграл коду после транслятора Си, где конкретно в этом месте была ещё одна лишняя косвенность. То есть процессор заточили под типовой код (таблицу переходов), он спокойно лишний раз читал память, что мешало ему делать лишние предсказания, на чём и обыграл человека.

Ответить | Правка | Наверх | Cообщить модератору

122. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от Аноним (81), 02-Мрт-24, 22:55 
> +;    Переход никогда не происходит. Предотвращает предсказания следующего
> +;    косвенного перехода, во многих случаях некорректные.

На всякий, это давно не так.

"Не переход" является таким-же учетным фактом как и "переход" для подавляющего большинства предсказателей, т.е. почти для всех актуальных ЦПУ с предсказателями (не только штеудовских ядер).
Упрощенно, предсказывается не факт перейдем/не перейдем, а адрес перехода (как вариант в координатах uops-кеша), а по факту корректируется статистика угадали или нет+актуальный_адрес.

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

На более сложных предсказателях, с буфером истории, может происходить масса эффектов. В частности, тут существует отдельная проблема/задача разделение всего графа/потока переходов, на фрагменты по которым есть ресурсы/возможность накапливать статистику. Например, упрощенно, для фрагмента кода с 6 переходами из всех 64 вариантов 4 могут быть наиболее вероятными, а какие 32 совсем холодными. Но проблема начинается с выбора начала фрагмента, и одна из эвристик тут - начинать фрагмент с перехода, которому не нужна история, т.е. с добавленного патчем jc.

Далее, в реальном коде загрузка опкода в регистр будет с дополнением нулями. Соответственно, CF всегда и гарантированно будет 0. Подобные ситуации используются штеудом для реализации "косвенного управления" (при трансляции инструкций в uosp участвует микрокод, который детектирует подобные паттерны и вставляет отдельные специфические uops-команды в конвейер).

Так вот, весьма вероятно, что использованный паттерн либо генерирует upos отключения предсказателя для следующего перехода, либо подсказывает поставить pivot point для отметки начала фрагмента для накопления статистики переходов.

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

Ответить | Правка | Наверх | Cообщить модератору

151. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от n00by (ok), 03-Мрт-24, 12:13 
>> +;    Переход никогда не происходит. Предотвращает предсказания следующего
>> +;    косвенного перехода, во многих случаях некорректные.
> На всякий, это давно не так.

У меня про данный частный случай. В цитате выше я восстановил комментарии, закрытые в исходном сообщении звёздочками.

execute_instruction:
    mov    eax, [opcode]
    shl    rax, instruction_size_log2
+;    Переход никогда не происходит. Предотвращает предсказания следующего
+;    косвенного перехода, во многих случаях некорректные.
+    jc    .stop
    lea    rax, [rax + vm_base + vm_base_lbl - execute_instruction]
    next_opcode
    jmp    rax
-    ud2
+.stop:    ud2

> "Не переход" является таким-же учетным фактом как и "переход" для подавляющего большинства
> предсказателей, т.е. почти для всех актуальных ЦПУ с предсказателями (не только
> штеудовских ядер).

В данном случае процессор не знает значение opcode, потому предполагает возможность перехода и видит его целью ud2.

Я наивно последовал правилу:

Assembly/Compiler Coding Rule 14. (M impact, L generality) When indirect branches are
present, try to put the most likely target of an indirect branch immediately following the indirect
branch. Alternatively, if indirect branches are common but they cannot be predicted by branch
prediction hardware, then follow the indirect branch with a UD2 instruction, which will stop the
processor from decoding down the fall-through path.

но без "неперехода" предиктор упорно заставлял процессор начинать исполнять следующую после ud2 команду.

Может быть там надо было два раза подряд ud2 поставить, как в том анекдоте, но у меня не стояла задача оптимизировать, потому не разбирался в деталях. Надо было проверить пару гипотез, для чего пришлось переписать с Си на асм (таблицу переходов выкинул - это не оптимизация, а упрощение кода). Когда в итоге код на асме заработал вдвое медленнее, пришлось дотягивать его до уровня компилятора.

> Упрощенно, предсказывается не факт перейдем/не перейдем, а адрес перехода (как вариант
> в координатах uops-кеша), а по факту корректируется статистика угадали или нет+актуальный_адрес.

Да, тут игнорируется расширение нулями 32-разрядного eax (что гарантирует неисполнение перехода), либо ud2 имеет приоритет, как команда остановить декодирование.

>[оверквотинг удален]
> начинать фрагмент с перехода, которому не нужна история, т.е. с добавленного
> патчем jc.
> Далее, в реальном коде загрузка опкода в регистр будет с дополнением нулями.
> Соответственно, CF всегда и гарантированно будет 0. Подобные ситуации используются штеудом
> для реализации "косвенного управления" (при трансляции инструкций в uosp участвует микрокод,
> который детектирует подобные паттерны и вставляет отдельные специфические uops-команды
> в конвейер).
> Так вот, весьма вероятно, что использованный паттерн либо генерирует upos отключения предсказателя
> для следующего перехода, либо подсказывает поставить pivot point для отметки начала
> фрагмента для накопления статистики переходов.

Так и как писать на ассемблере? Это лишь малая часть необходимых знаний, что бы обогнать транслятор. Оратор, кому я отвечал, утверждал, что это элементарно. Мне пришлось когда-то посидеть с AMD CodeAnalyst, где проводилась симуляция конвейера и микрооперации можно было увидеть глазами, потому на автомате могу написать получше некоторых, и то сел в лужу.)

Разве что в образовательных целях писать: у AMD64 достаточно регистров, системные вызовы в Linux проще любимого некоторыми DOS-а, нет бестолковой возни с сегментами.

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

Я узнал, что у Эльбруса отдельный стек для адресов возвратов, и задумался, как ещё возможно использовать стек данных. Проверил подручными средствами, реализовал стековую виртмашину, использовав аппаратный стек. На AMD64 пришлось всё затолкать в один стек, но сработало. На Эльбрусе, наверное, красивее должно смотреться, если бы к языку типа Си добавить возможность работать со стеком явно.

Ответить | Правка | Наверх | Cообщить модератору

64. "Обновление операционной системы MenuetOS 1.50, написанной на..."  –1 +/–
Сообщение от pic (?), 02-Мрт-24, 16:06 
Может сразу отказаться от x86 и создавать процессоры для исполнения байт-кода?
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

65. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +1 +/–
Сообщение от Аноним (2), 02-Мрт-24, 16:15 
Вроде уже делали с forth. И javacard наверно, да? Вот эта вполне популярна и повсеместна. По-сути своей, x86 -- тоже байткод, который исполняется на микрокоде и далеко не всё в нём реализовано напрямую в железе.
Ответить | Правка | Наверх | Cообщить модератору

70. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от Аноним (89), 02-Мрт-24, 16:52 
Была Sun-попытка году, эдак, в 1995-м - Java bytecode CPU.
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

73. "Обновление операционной системы MenuetOS 1.50, написанной на..."  –1 +/–
Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 17:03 
> Может сразу отказаться от x86 и создавать процессоры для исполнения байт-кода?

а чем по вашему представлены коды операций процессора (opcodes), разве не байтами? :)

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

76. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 17:09 
> Может сразу отказаться от x86 и создавать процессоры для исполнения байт-кода?

и вообще байт-код или бит-код совсем неудачные названия, нужно как-то i-code (interpretted code) или i-bcode (interpretted binary code) или ir-code как в случае с llvm или am-code (abstract machine code) или am-bcode (abstract machine binary code) обязательно подчеркнув бинарность.

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

78. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от Аноним (-), 02-Мрт-24, 17:25 
Всё уже изобретено до вас. Это называется pcode, Вирт чтобы не париться с портированием паскаля на 100500 платформ, портировал интерпретатор байткода, компилируя паскаль в байткод. И байткод он называл pcode, в смысле portable code.
Ответить | Правка | Наверх | Cообщить модератору

80. "Обновление операционной системы MenuetOS 1.50, написанной на..."  +/–
Сообщение от Sw00p aka Jerom (?), 02-Мрт-24, 17:34 
> Всё уже изобретено до вас.

так зачем продолжаем говорить байт-код?

> И байткод он называл pcode, в смысле portable code.

Ну вот, замечательно.

Bytecode (also called portable code or p-code) - ну и где логика? кто и зачем это ввел?


Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру