Здравствуйте, Disappear, Вы писали:
XC>>Причем первое важнее второго: я бы например мог написать сначала пару классов на Ди (естественно, доступных для С++-программы), дальше — например библиотеку, а затем уже и перейти к проектам. D>Вот тут есть одна проблемка, правда решаемая. У D есть бинарная совместимость для C, но нет таковой для C++ в виду большой сложности последней. Но никто не мешает написать некую библиотеку, которая позволяла бы оперировать с классами D из С++, и наоборот.
Библиотека изменяющая формат бинарных файлов? Это что-то новое.
D и С++ не совместимы. В этом весь прикол. Так что создать общий проект можно только при условии, что интеграция идет через С. А это означает "скажи классам досвиданья".
XC>>ИМХО, после этого количество пользователей D увеличилось бы в РАЗЫ.
Гы-гы.
D>Думаю, что это очень разумное предложение, D>еще нужно не забыть о том, что этот плагин должен позволять дебажиться в D.
Ребят. Интеграция для Ди делается. Только традиционно на C# (гы-гы). Вот только создать качественную интеграцию — это работа не сильно проше чем написать весь компилятор этого самого D. Так что не ждите чего-то сверхестественного в ближайшее время.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
У них видимо сайт глючит переодически. Днем нажимал на Pdf, а мне выскакивал левый диалог логина. Зарегистрироваться вообще не удовалось (тормозил и выдавал ошибку). Сейча вот открылся. Явные глюки. И это типа под патронажем Гугля .
ОК, попрогую глянуть. Спасибо.
C>Могу в своих свалках ссылок поискать.
Мне то уже не нужно. Но народу може окажется интересным. Вот EvilChild интересуется...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
XC>>>Причем первое важнее второго: я бы например мог написать сначала пару классов на Ди (естественно, доступных для С++-программы), дальше — например библиотеку, а затем уже и перейти к проектам. D>>Вот тут есть одна проблемка, правда решаемая. У D есть бинарная совместимость для C, но нет таковой для C++ в виду большой сложности последней. Но никто не мешает написать некую библиотеку, которая позволяла бы оперировать с классами D из С++, и наоборот.
VD>Библиотека изменяющая формат бинарных файлов? Это что-то новое. VD>D и С++ не совместимы. В этом весь прикол. Так что создать общий проект можно только при условии, что интеграция идет через С. А это означает "скажи классам досвиданья".
Может имелся в виду линкер, который бы понимал и Сишные, и С++ные, и D-шные объектники? (ну и еще чтобы компилятор D понимал С++-ные h-файлы... не знаю как там с этим). Думаю это не настолько сложно как создать компилятор.
Вообще, с линкерами проблема: например, недавно парился с тем, что линкер в 2003 студии не видит ресурсы, включенные в библиотеку. Наверняка в исходниках линкера пару строчек исправить, а вот нет, не исправили (это еще с VS6 идет)
Здравствуйте, x-code, Вы писали:
XC>Может имелся в виду линкер, который бы понимал и Сишные, и С++ные, и D-шные объектники? (ну и еще чтобы компилятор D понимал С++-ные h-файлы... не знаю как там с этим).
Я кажется ясно сказал "D и С++ не совместимы.".
XC>Думаю это не настолько сложно как создать компилятор.
Это не сделано. А сложно или нет осбуждаеть смысла нет. Автор говорит, что сложно.
XC>Вообще, с линкерами проблема: например, недавно парился с тем, что линкер в 2003 студии не видит ресурсы, включенные в библиотеку. Наверняка в исходниках линкера пару строчек исправить, а вот нет, не исправили (это еще с VS6 идет)
Это проблемы МС. В принципе С++ от линкера не зависит. Лиш бы оный поддерживал длинные имена функций. Но конечно каждый производитель вносит свои изменения и они все между собой не совместимы.
С++ вообще никак не описывает бинарную совместимость в следствии чего в этой области полная вакханалия. Вот Ява и дотнет другое дело, но Ди и с ними не совместим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Не пора ли нам перейти на D или что-нибудь вроде этог
[]
OCT>почему бы не признать наконец, что горы используемого ныне софтваря — хлам. Операционка, в которой я сижу, — хлам. Браузер, в котором я пишу, — хлам. Сегодня он работает, а завтра для него найдут сплойт. И так, много про что, можно сказать.
Да, например, про рантаймы и компиляторы безопасных языков
Кстати, пресловутое переполнение буфера возникает (вопреки ошибочному мнению) не из-за отсутствия проверок на выход за пределы массива (которые есть не только в С++, но даже в x86 ассемблере) и т.п. при обработке данных, а из-за отсутствия валидации этих данных на входе, что является ошибкой в логике. Подобная ситуация может привести к многим другим способам инекции кода (eval/ASP/PHP/SQL/... injection), либо к отказу в обслуживании.
[]
OCT>Я считаю, целостность — минимальное требование. Поэтому C/C++ я считаю хламом. Историческую функцию они исполнили (когда нужно лишь бы работало). Я считаю, нужно давно что-то менять. Вы можете признавать это, можете нет, это ваше дело.
OCT>Взять в качестве только D, я считаю, сильное ограничение. Почему D? Почему не Eiffel или Ada?
Because of the different flight path, a data conversion from a 64-bit floating point to 16-bit signed integer value caused a hardware exception (more specifically, an arithmetic overflow, as the floating point number had a value too large to be represented by a 16-bit signed integer). Efficiency considerations had led to the disabling of the software handler (in Ada code) for this error trap, although other conversions of comparable variables in the code remained protected. This led to a cascade of problems, culminating in destruction of the entire flight.
Из серебра делают монеты, а не пули.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, WolfHound, Вы писали:
WH>Нет у нативности никаких преимуществ. Вобще никаких. Он не нужен нигде. Ну кроме может быть микрокода и чегото в этом духе.
Я с этим категорически... не пойму, согласен или нет Ведь по сути x86 опкоды выполняются на некоей RISC машине. Осталось доработать это дело, что бы выполнял MSIL. Догнать Java
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
WH>>Нет у нативности никаких преимуществ. Вобще никаких. Он не нужен нигде. Ну кроме может быть микрокода и чегото в этом духе. GN>Я с этим категорически... не пойму, согласен или нет Ведь по сути x86 опкоды выполняются на некоей RISC машине. Осталось доработать это дело, что бы выполнял MSIL. Догнать Java
Дык без проблем. Java-процессоров на рынке — завались. Выбирай на любой вкус.
Модель виртуальной машины в .NET/JVM — стековая, и не особо подходит для быстрого выполнения на реальном железе (а у .NET так вообще неприспособлена совершенно из-за generic арифметических инструкций). Ее надо предварительно превратить в нормальный промежуточный код.
Здравствуйте, Cyberax, Вы писали:
C>Дык без проблем. Java-процессоров на рынке — завались. Выбирай на любой вкус.
Я вобщем-то и намекал, что нативный код — понятие относительное
C>Модель виртуальной машины в .NET/JVM — стековая, и не особо подходит для быстрого выполнения на реальном железе (а у .NET так вообще неприспособлена совершенно из-за generic арифметических инструкций). Ее надо предварительно превратить в нормальный промежуточный код.
Разные по размеру опкоды x86 тоже плохо подходят для выполнения на высокочастотных ядрах, поэтому разбиваются на микрооперации (JIT компиляция ).
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
C>>Дык без проблем. Java-процессоров на рынке — завались. Выбирай на любой вкус. GN>Я вобщем-то и намекал, что нативный код — понятие относительное
Ну так это понятно.
C>>Модель виртуальной машины в .NET/JVM — стековая, и не особо подходит для быстрого выполнения на реальном железе (а у .NET так вообще неприспособлена совершенно из-за generic арифметических инструкций). Ее надо предварительно превратить в нормальный промежуточный код. GN>Разные по размеру опкоды x86 тоже плохо подходят для выполнения на высокочастотных ядрах, поэтому разбиваются на микрооперации (JIT компиляция ).
Тут фича в том, что для x86 это достаточно просто сделать. А для Java-байткодов придется делать такие вещи, как оптимизированое распределение регистров, а для этого уже нужно строить полный CFG функций. Ну а это уже совершенно непрактично в железе.
Господа — это жесть столько сообщений в теме )))))
Вот я пытаюсь понять одно: чтобы хоть как-то юзать одновременно С++ и так называемый D некоторые предлагают такоое замутить, что я бы сказал: зачем что-то делать для совместимости, если просто можно остаться на "старом языке"...
Не все новое хорошое !
И все таки мне кажется коммерческие проекты на языке, который я к примеру только что услышал (значит больше половины еще о нем даже не слышали) делать просто глупо. IMHO.
PS: или я не так все понял...
PSS: Может сделаем язык E ? (хотя может уже и есть)
Здравствуйте, Cyberax, Вы писали:
C>Тут фича в том, что для x86 это достаточно просто сделать. А для Java-байткодов придется делать такие вещи, как оптимизированое распределение регистров, а для этого уже нужно строить полный CFG функций. Ну а это уже совершенно непрактично в железе.
А раз всеравно делать полноценный анализ то нафига вобще арифметику в виртуальную машину хардкодить?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Тут фича в том, что для x86 это достаточно просто сделать.
Реальная причина другая — делать это требует рынок. Есть более простые способы получить лучшую произволительность, пример Itanic'а показал их жизнестойкость. Если MS доведут Сингулярность до ума (а они это сделают в том или ином виде, пусть и под другим названием) — такое железо появится. Фишка в том, что гигагерцы там не обязательны, для десктопа хватит подобного проца с частотой в сотню-другую мегагерц, для телефонов — подавно.
C>А для Java-байткодов придется делать такие вещи, как оптимизированое распределение регистров, а для этого уже нужно строить полный CFG функций. Ну а это уже совершенно непрактично в железе.
Зачем регистры, там же стековая машина.
Процессоры оптимизируют под языки. Как Керниган и Риччи заменили синтаксис ассемблера PDP на более "красивный" кросплатформенный, так и понеслось развитие в этом направлении. И вошло в замкнутый круг. Вот вроде бы революционная технология HT — попытка параллельного выполнения команд одним ядром. Но это плохо вписывается в модель PDP, поэтому реально даже тормоза оказылись. А если бы повсеместно писали на Erlang, кто знает, нужны ли бы были многоядерные процы с изоляцией ядер и громоздким механизмом межпроцессорного взаимодействия, не лучше ли иметь проц с большим набором регистров, каждый из котрых может служить и instruction pointer.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, WolfHound, Вы писали:
C>>Тут фича в том, что для x86 это достаточно просто сделать. А для Java-байткодов придется делать такие вещи, как оптимизированое распределение регистров, а для этого уже нужно строить полный CFG функций. Ну а это уже совершенно непрактично в железе. WH>А раз всеравно делать полноценный анализ то нафига вобще арифметику в виртуальную машину хардкодить?
Мы уже об этом флеймили
Такие вещи, как аримфетика или векторные инструкции лучше пусть будут в наборе инструкций. Ну и для JVM у нас еще получается бенефит в виде возможности быстрой интерпретации.
Здравствуйте, gear nuke, Вы писали:
C>>Тут фича в том, что для x86 это достаточно просто сделать. GN>Реальная причина другая — делать это требует рынок. Есть более простые способы получить лучшую произволительность, пример Itanic'а показал их жизнестойкость. Если MS доведут Сингулярность до ума (а они это сделают в том или ином виде, пусть и под другим названием) — такое железо появится. Фишка в том, что гигагерцы там не обязательны, для десктопа хватит подобного проца с частотой в сотню-другую мегагерц, для телефонов — подавно.
Какие "другие пути"?
x86 сейчас по совокупности показателей — самый быстрый, разве что новые POWER от IBM могут соперничать. По каким-то показателям другие процессоры могут обходить x86 (тот же Itanium может делать больше параллельных операций, но x86 его побьет в последовательном коде).
100-200Мгц для десктопа — в любом случае фантастика. Я работаю с MIPS-процессором на 175MHz (в ADM5120P, если кому интересно), работает быстрее Pentium'а аналогичной частоты, но не сильно быстрее.
Могут помочь асинхронные процессоры, но пока они за гранью доступной сложности проектирования.
C>>А для Java-байткодов придется делать такие вещи, как оптимизированое распределение регистров, а для этого уже нужно строить полный CFG функций. Ну а это уже совершенно непрактично в железе. GN>Зачем регистры, там же стековая машина.
А стековая машина в железе неэффективна. Точнее, она будет очень простой и иметь хорошее отношение скорость/энергопотребление, но вот быстрой она не будет. ФОРТ-процессоры уже это проверили.
GN>Процессоры оптимизируют под языки. Как Керниган и Риччи заменили синтаксис ассемблера PDP на более "красивный" кросплатформенный, так и понеслось развитие в этом направлении. И вошло в замкнутый круг. Вот вроде бы революционная технология HT — попытка параллельного выполнения команд одним ядром. Но это плохо вписывается в модель PDP, поэтому реально даже тормоза оказылись.
Нормально оно вписывается.
GN>А если бы повсеместно писали на Erlang, кто знает, нужны ли бы были многоядерные процы с изоляцией ядер и громоздким механизмом межпроцессорного взаимодействия, не лучше ли иметь проц с большим набором регистров, каждый из котрых может служить и instruction pointer.
Были и такие варианты — тот же Itanium (там за сотню регистров, AFAIR). Swap между любым регистром и IP там тоже возможен.
Вот только ВСЕ современные процессоры построены по конвеерному принципу и смена IP ведет к перезагрузке ВСЕГО контейнера, а это медленно. А еще, не дай бог, попадешь на cache miss...
Поэтому в современных x86 есть очень крутой и мощный branch predictor и планировщик, которые как раз отвечают за большую часть сложности процессора. Если их выбросишь — получишь тормозной процессор.
Здравствуйте, Cyberax, Вы писали:
WH>>А раз всеравно делать полноценный анализ то нафига вобще арифметику в виртуальную машину хардкодить? C>Мы уже об этом флеймили
И в прошлый раз так и небыло показано никаких преимуществ хардкода арифметики в модель ВМ. Но были показаны проблемы на примере тогоже .NET 2
C>Такие вещи, как аримфетика или векторные инструкции лучше пусть будут в наборе инструкций.
Нечего им там делать.
C>Ну и для JVM у нас еще получается бенефит в виде возможности быстрой интерпретации.
Интерпритацию в морг.
Она может быть допустима только в случае управляющих комманд для чегото гораздо болие тяжолого.
А если она выполняет основные вычисления то точно в морг.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>А раз всеравно делать полноценный анализ то нафига вобще арифметику в виртуальную машину хардкодить? C>>Мы уже об этом флеймили WH>И в прошлый раз так и небыло показано никаких преимуществ хардкода арифметики в модель ВМ. Но были показаны проблемы на примере тогоже .NET 2 C>>Такие вещи, как аримфетика или векторные инструкции лучше пусть будут в наборе инструкций. WH>Нечего им там делать.
Ты можешь примерно набросать идею своей VM? Сейчас снова ожил проект http://hlvm.org/ — это как раз проект создания обобщенной виртуальной машины на базе LLVM. Может им полезно будет.
C>>Ну и для JVM у нас еще получается бенефит в виде возможности быстрой интерпретации. WH>Интерпритацию в морг.
Благодаря ей у нас есть HotSpot в JVM. В теории, можно было бы заменить на многостадийную JIT-компиляцию, но сложность уже намного больше будет.
WH>Она может быть допустима только в случае управляющих комманд для чегото гораздо болие тяжолого. WH>А если она выполняет основные вычисления то точно в морг.
Реально помогает, тем не менее.
.
Ведь по сути x86 опкоды выполняются на некоей RISC машине. Осталось доработать это дело, что бы выполнял MSIL. Догнать Java 
