SharpOS - открытая ОС, целиком написанная на языке C#

>>Ex, ну и какие же? Не молчите!

первое что пришло в голову - формат дескриптора сегмента

И что с ним не так?

> первое что пришло в голову - формат дескриптора сегмента

Да, веский недостаток _архитектуры_. Сколько процентов команд, исполняющихся за 1сек, имеют дело с дескрипторами сегмента?

порой так забавно наблюдать за войной анонимусов )))

> порой так забавно наблюдать за войной анонимусов )))

Потыкай в них палочкой ;)

скоро на питоне операционки начнут писать. ПиДос , комуто такое название будет по душе.

Пиндосам?

>>Да, веский недостаток _архитектуры_. Сколько процентов команд, исполняющихся за 1сек, имеют дело с дескрипторами сегмента?

красота должна быть во всем =]

> Во-первых еще на примере форта было показано что нормальные реализации байт-кода умеют работать практически без потери производительности

ЕМНИП, стековость форта и шитый код не способствуют достижению максимальной производительности из-за перезагрузки линий кеша при JMP-ах. Поэтому для максимальной эффективности код должен исполняться на форт-процессоре, который на аппаратном уровне (зашитом в FPGA, например) реализует форт на уровне ассемблера (имеем некоторые вариации, какие конкретно "слова" форта взять за базовые, из чего составить "байт-код").

> да что вы говорите? какие ограничения могут быть

... made by 2-bit minded people, who can't stand a bit for competition :))

Текст новости скопипастен с http://www.opennet.ru/opennews/art.shtml?num=13509

> по поводу сборщиков мусора: <..>А вот удаление из памяти - проблема

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

Ну так есть же жаба-процессоры, на тех же айбиэмовских мейнфреймах, в чём же форт лучше чем жаба? За тем лишь исключением, что форт -- это что-то древнее и ныне не используемое.

Извиняюсь за подтверждение копипаста. Поставил ссылку на опеннет.ру Пиначету - предупреждение.

>Вот и мне тоже так кажется. CISC-инструкции x86 переводятся на аппаратном уровне во внутренние RISC-инструкции, в итоге работают даже быстрее настоящих RISC-процессоров.

Само собой, напрашивается вопрос, нафига надстройка CISC ???

А про ошибки округления ... я вообще молчу.

> напрашивается вопрос, нафига надстройка CISC ???

А ты подумай... вдруг догадаешься?

>А ты подумай... вдруг догадаешься?

Это что бы бабло вытрясать из чайникафф ? да ?

Ведь "выдумав" и реализовав ещё одну супер-быструю команду в своём новом процессоре (посредством написания микропрограммы для RISC ядра) стимулируются продажи. :)

> когда появится массово поддержка джава байт кода в процессорах

Sun уже такой процессор делала, PicoJava назывался, ну и где он теперь? на свалке истории

>>А ты подумай... вдруг догадаешься?

если бы от этой @#$ совместимости отказались во времена 80386, все могло сложиться иначе.

Как иначе-то? Ex, хватит уже троллить. Чем тебя конкретно не устраивает x86? CISC'ом?

RISC выбрали потому что он был быстрее. А CISC медленне. Сейчас один фиг, фактически x86 уже RISC'ом стал. Так что неактуально твои замечания насчёт команд.

>> когда появится массово поддержка джава байт кода в процессорах

> Sun уже такой процессор делала, PicoJava назывался, ну и где он теперь? на свалке истории

многие ARM SoC имеют в составе ядра ограниченную поддержку аппаратного ускорения Java (google ARM Jazelle)

> стимулируются продажи

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

>>RISC выбрали потому что он был быстрее. А CISC медленне. Сейчас один фиг, фактически x86 уже RISC'ом стал. Так что неактуально твои замечания насчёт команд.

так почему бы не внести небольшое дополнение в виде опционально отключаемой трансляции x86 CISC -> RISC для исполнения native x86 RISC op's?

>Продажи стимулируются не командами, а сговором с разработчиками ПО, которые вынуждают покупать более быстрые процессоры

Скорее с одним из них :)

>Чем тебя конкретно не устраивает x86?

Дурными регистрами.

> в виде опционально отключаемой трансляции x86 CISC -> RISC

Потому что никому не надо это уже. Особенно в свете того, что есть всякие MMX, SSE2, SSE3, команды виртуализации и прочее...

> Дурными регистрами.

Что в них дурного? Слушать тебя не хотят? :))

>>Как иначе-то? Ex, хватит уже троллить. Чем тебя конкретно не устраивает x86? CISC'ом?

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

Да чего спорить, x86 и CISC вообще - умирающая архитектура, если бы не совместимость тонны закрытого софта, ее бы уже давно бросили. Никто не видит будущего у x86.

>Особенно в свете того, что есть всякие MMX, SSE2, SSE3, команды виртуализации и прочее..

Почитайте про мейнфреймы, там виртуализация давно и намного лучше. Что толку от MMX SSE* если шина всё равно тормоз :)

>> Что в них дурного? Слушать тебя не хотят? :))

сравни ка например arm и x86 архитектуры

> эмуляция, мой друг

Я тебе уже сказал, что интеловский CISC быстрее нативного риска работает, тебя коробит от самой эмуляции? Ну так купи себе риск какой-нить и не *** мозги другим, утверждая, что он лучше/выше/сильнее.

Чистые RISC будут совместимы друг с другом только в рамках одного производителя и поколения процов. Линукс-то легко каждый раз портировать, но вот венда тока на хы86 пашыт.

> Почитайте про мейнфреймы

Почитайте прайс-листы на эти мейнфреймы ;)))

>> MMX

вы в курсе какие регистры используют mmx комманды?

> сравни ка например arm и x86 архитектуры

Разговор с тобой ниочём. Я тебя спросил, что конкретно, ты отмазался каким-то сомнительным дескриптором. Никаких фактов, тестов, примеров кода и т.п. ты не привёл.

> вы в курсе какие регистры используют mmx комманды?

А-таки ви?

>> А-таки ви?

вам таки удобно комбинировать fpu и mmx комманды с условием того что собственно используют они одни и те же регистры???

> используют они одни и те же регистры

4.2

> вам таки удобно

Вам-таки удобно для ПК писать? Может вам лучше калькулятор использовать, там команд меньше...

Эко дерьмо

>>4.2

7) Обнуление FPU регистров (Emms) – обязательно должно стоять после всех MMX процедур, т.к регистры mm0-mm7 заодно являются мантиссой регистров математического сопроцессора (st0-st7).

Ex, ты уныл как никто другой на этом ресурсе. Можешь гордиться или плакать. Даже ссаныч с гхариком менее унылы, чем ты.

>> Вам-таки удобно

пг'астите, ви таки евг'ей?

> пг'астите, ви таки евг'ей?

Нет, я `ГЫД.

Михаил, таки перелогиньтесь!

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

PS. Быдлоязыки и быдлотехнологии, вместе с быдло-ос в топку.

> в чём же форт лучше чем жаба?

хотя бы тем, что на форте можно реализовать ALU и остальные блоки процессора. Он почти аналогичен VHDL.

см. например, http://winglion.ru/board/viewtopic.php?t=33

c нуля описали систему команд процессора, ALU, запрограммировали процессор, создали опкод-байткод.

задача проста. где по данной ниже ссылке автор делал "ошибки", в результате которых код java исполнялся быстрее? http://kano.net/javabench/