Здравствуйте, Sinclair, Вы писали:
S>Я не вполне себе представляю сигнатуру eval() в строго статически типизированном языке. (void*)? Но там же офигенный риск ошибки типизации, которая в неуправляемом языке имеет катастрофические последствия.
Там и так по любому рискуешь этой ошибкой. Так что принципиального ухудшения не будет.
N>> Memory at f2000000 (32-bit, non-prefetchable) [size=16M]
N>> Memory at e8000000 (64-bit, prefetchable) [size=128M]
N>> Memory at f0000000 (64-bit, prefetchable) [size=32M]
N>> I/O ports at e000 [size=128]
S>Там же 3 куска, но я догадываюсь, что енто непрерывный адрес,
В каком смысле?
S> только к чему такая разбивка (128+32, а не 160)?
PCI позволяет выделять адресное пространство только степенями двойки.
Почему 3 куска в сумме 176, а не один на 256 — надо спрашивать дизайнера карты. Я не в курсе. Возможно, заточка на работу в 32-битных ОС требует такой оптимизации.
Здравствуйте, netch80, Вы писали: N>Там и так по любому рискуешь этой ошибкой. Так что принципиального ухудшения не будет.
Конечно же будет. Для "обычной" программы у нас есть возможность статически проверить типы и убедиться, что она делает более-менее то, что нам нужно.
Даже те места, где у нас идёт небезопасный каст, обычно применяются к заранее известному типу данных. То есть при приведении void* data к MY_STRUCT* у нас есть причины полагать, что в data — именно MY_STRUCT.
В динамике там может быть всё, что угодно. У нас должны быть какие-то способы ограничить тексты, которые будет успешно прожёвывать eval() или compile().
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
>Я не вполне себе представляю сигнатуру eval() в строго статически типизированном языке. (void*)? Но там же офигенный риск ошибки типизации, которая в неуправляемом языке имеет катастрофические последствия.
А как определятся интерфейс загрузки функции из DLL? Вот так примерно и определяется, возвращает (void*), а остальное — проблема пользователя.
Не надо воспринимать строгую статическую типизацию, как некую религиозную догму. Статическая типизация — удобная и полезная штука, но в некоторых случаях приходится делать unsafe.
Но я, впрочем, не сторонник внесения в стандарт Си функций типа eval/compile. В общем виде их нормально не реализуешь на большинстве популярных платформ.
Здравствуйте, Pzz, Вы писали:
Pzz>А как определятся интерфейс загрузки функции из DLL? Вот так примерно и определяется, возвращает (void*), а остальное — проблема пользователя.
Ну, в случае DLL у нас помимо ISO стандарта на язык есть определённые договорённости о calling convention плюс спецификация библиотеки, которые позволяют нам более-менее полагаться на стабильность результатов приведения void* к нужному нам типу. Ну, то есть теоретически мы знаем, что можно подложить левую DLL, и там вообще всё-всё взорвётся. Но на практике у нас есть более-менее работающие практики по согласованию вызовов.
Про compile()/eval() я себе не очень представляю, как получить хотя бы как-то работающую реализацию. Откуда будут браться тексты, которые туда будут скормлены?
Если это какой-то набор фиксированных источников, то наверное проще их все скомпилировать заранее и хранить сразу в пригодном для вызова виде.
Если это какая-то полная динамика, не входящая в наш цикл разработки, то она полностью бесполезна без методик контроля валидности.
Ну, то есть если мы хотим иметь какую-то интерактивную программу, в которую, как в ексель, вводится формулка, и мы интегрируем вызов этой формулки в нашу программу, то вот такой вот "небезопасный eval" — это худший возможный вариант. Чуть не то набрал — хлоп, page fault, приехали (это в лучшем случае).
Pzz>Но я, впрочем, не сторонник внесения в стандарт Си функций типа eval/compile. В общем виде их нормально не реализуешь на большинстве популярных платформ.
Ну вот то-то и оно. В общем, непонятна мотивация и сценарии использования этого eval().
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Про compile()/eval() я себе не очень представляю, как получить хотя бы как-то работающую реализацию. Откуда будут браться тексты, которые туда будут скормлены?
В языке Go существенная часть компилятора является частью стандартной библиотеки. А именно, полноценный настоящий парсер и алгебра типов. Благодаря этому всякие полезные програмки для работы с Go понимают синтаксис языка, а не пытаются его угадать с помощью регуляных выражений и творческой смекалки автора, что весьма удобно.
Если бы так же сделали с Си, в этом был бы смысл. А целый компилятор с кодогенераровом в библиотеку засовысать, я не знаю, зачем это нужно.
Здравствуйте, Pzz, Вы писали:
Pzz>Если бы так же сделали с Си, в этом был бы смысл. А целый компилятор с кодогенераровом в библиотеку засовысать, я не знаю, зачем это нужно.
А зачем вообще парсить код, если его не исполнять?
Здравствуйте, netch80, Вы писали:
N>А зачем вообще парсить код, если его не исполнять?
В случае с Go это полезно для написания всяких генераторов и анализаторов. Я не видел еще не одного проекта, который бы в рантайм что-то парсил, но вот нагенерировать всякого барахла и потом его использовать — это удобно.
Здравствуйте, Mystic Artifact, Вы писали:
MA>Цена действительно качественного JIT — около 50Mb исполнимого кода. Что там наркоманы в Го творят — это никому не интересно.
Здравствуйте, netch80, Вы писали:
Pzz>>Если бы так же сделали с Си, в этом был бы смысл. А целый компилятор с кодогенераровом в библиотеку засовысать, я не знаю, зачем это нужно.
N>А зачем вообще парсить код, если его не исполнять?
Чтобы всякие тузлы можно было написать, которые с кодом работают. Например "переименовать поле в классе CCC из XXX в YYY", или "построить список мест, откуда вызывается функция FFF" — куда как аккуратнее решается, если тулза способна по-настоящему распарсить текст, чем если она пытается угадать с помощью регулярных выражений, как это нередко делается.
Здравствуйте, Sinclair, Вы писали:
S>В динамике там может быть всё, что угодно. У нас должны быть какие-то способы ограничить тексты, которые будет успешно прожёвывать eval() или compile().
Ну, например, компилятор мог бы передавать eval'у, какой тип ожидается на выходе, а eval бы в рантайме проверял, получилось у него, или нет.
Здравствуйте, ononim, Вы писали:
O>Кствти, совпадение или нет, но последний кукурузо увидел свет аккурат через год после появления первого x86-64 камня. Вся эта внутренняя гибкость так и не позволила осилить декодирование новых опкодов.
Исполнение, скорее. Если у тебя есть декодер команд 386, то доделать его, чтобы он x86 понимал, несложно. Но что с этими декодированными командами делать, если у тебя нету 64-битных регистров и ALU?
Здравствуйте, 0xCAFEDEAD, Вы писали:
A>>Ты точно программист? A>>Ты не знаешь, насколько труднее поддерживать чужую программу, чем писать свою?
CAF>Не понял. Ты думаешь, что поддерживать свою архитектуру проще чем реализовать чужую?
Да, да, да, да, да и ещё триста раз да!
Более того, ты не сможешь привести ни одного современного примера поддержки чужой архитектуры.
Купить (с грехом пополам как AMD) ещё можно, самостоятельно воспроизвести — никогда.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Здравствуйте, alpha21264, Вы писали:
A>>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
A>>Чем не устраивает ответ "как обычно"?
CAF>А обычно это как?
Как всегда.
Сейчас ты идёшь в магазин и покупаешь компьютер.
И хотя ты в магазине платишь рубли,
с каждого купленного компьютера Россия теряет,
а США приобретают примерно тысячу долларов.
В случае российского компьютера эту штуку баксов
будут получать русские инженеры и рабочие.
Даже если русский компьютер будет в десять раз дороже,
Россия в целом станет на эту штуку баксов богаче.
Вот потому так истерят наши США-нские (хотел сказать коллеги) оппоненты.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, a7d3, Вы писали:
A>>>Такое впечатление, что ты знаешь систему команд Эльбруса. A>>>Поделись информацией!
A>>Есть книжка раздаваемая официально http://www.mcst.ru/doc/book_121130.pdf
A>Ну так система команд-то где? A>Информационного шума (маркетингового булшита) дохрена, но где конкретная информация?
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, 0xCAFEDEAD, Вы писали:
A>>>Ты точно программист? A>>>Ты не знаешь, насколько труднее поддерживать чужую программу, чем писать свою?
CAF>>Не понял. Ты думаешь, что поддерживать свою архитектуру проще чем реализовать чужую?
A>Да, да, да, да, да и ещё триста раз да! A>Более того, ты не сможешь привести ни одного современного примера поддержки чужой архитектуры. A>Купить (с грехом пополам как AMD) ещё можно, самостоятельно воспроизвести — никогда.
Так вроде те же МЦСТ вполне спокойно и СПАРК выпускают. Архитектура открытая, прцессор свой.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Здравствуйте, alpha21264, Вы писали:
A>>>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>>>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
A>>>Чем не устраивает ответ "как обычно"?
CAF>>А обычно это как?
A>Как всегда. A>Сейчас ты идёшь в магазин и покупаешь компьютер. A>И хотя ты в магазине платишь рубли, A>с каждого купленного компьютера Россия теряет, A>а США приобретают примерно тысячу долларов.
Ну это уж ты подзагнул.
A>В случае российского компьютера эту штуку баксов A>будут получать русские инженеры и рабочие. A>Даже если русский компьютер будет в десять раз дороже, A>Россия в целом станет на эту штуку баксов богаче.
Вообще-то мы это уже проходили в СССР. Я помню эти советские компьютеры. Кстати, были XT/AT совместимые
Но в общем это путь в никуда. Это хорошо поддержать своих, но в разумных пределах. И вопрос не в том, зачем Рос компьютер, а зачем своя архитектура. Ведь там даже gcc нет. Нужно свой компилятор поддерживать, и все им собирать. Об остальных языках я вообще молчу.
A>Вот потому так истерят наши США-нские (хотел сказать коллеги) оппоненты.
Вообще-то я в США живу ныне. А мы не в политике, и разговор именно как о перспективах техники. Я же сразу написал, и не раз повторял. Свой процессор, свое производство, и тд может быть вопросом безопастности, обсуждать нет сысла. Именно вопрос об использовании оригинальной архтектуры.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Но в общем это путь в никуда. Это хорошо поддержать своих, но в разумных пределах. И вопрос не в том, зачем Рос компьютер, а зачем своя архитектура. Ведь там даже gcc нет. Нужно свой компилятор поддерживать, и все им собирать. Об остальных языках я вообще молчу.
A>>Вот потому так истерят наши США-нские (хотел сказать коллеги) оппоненты.
CAF>Вообще-то я в США живу ныне. А мы не в политике, и разговор именно как о перспективах техники. Я же сразу написал, и не раз повторял. Свой процессор, свое производство, и тд может быть вопросом безопастности, обсуждать нет сысла. Именно вопрос об использовании оригинальной архтектуры.
Использование CISC изжило свое, архитектура x86 уперлась в тупик и превратилась в RISC прикидывающийся CISC ради обратной совместимости с уже существующими гига и терра-тоннами двоичного кода.
Архитектуры VLIW / EPIC являются естественным продолжением в эволюционном развитии персональных компьютеров с процессорами общего назначения. Имея в теории и демонстрируя на практике ряд преимуществ, включая большую энерго-эффективность и меньшие требования к производственному техпроцессу. При массовом переходе широких слоев населения на подобное железо можно получить более разумное расходывание энергоресурсов как при эксплуатации, так производстве этих самых ЦПУ.
Компилятор уже есть, gcc-совместимый оптимизирующий, собирающий аж три дистрибутива линукса. Два из которых это Debian derivative'ы, а другой RPM based самопал с долгой историей на основе французского Mandrake. Т.е. пакетные дистрибы предоставляющие репозитории с двоичными пакетами прикладного софта — собирается не только ядро и «мир», но и прикладной софт в этих репозиториях.
