Здравствуйте Xentrax, Вы писали:

X>Здравствуйте Edmond, Вы писали:

X>
X>>>Как оказалось, Win32 можно перенести куда угодно. Даже на устройства с 4 — 8 мегами памяти, не говоря уже о современных 64-128 с флешками по 512 мб

E>>??? Например???

X>Да полно таких, ключевой слово — Windows CE.

Ловлю на слове: полно таких... пример Windows CE )))))))))))))))))))))))))
Вам не смешно?


X>Ага, еще как. Особенно когда им предлагают выпустить японскую версию



E>>Конечно, елси так подходить к прогарммированию, то про переносимость можно забыть.

E>>А что переносимоть????

X>Переносимость — это когда код не требует серьезной переделки, чтобы работаьт где-то еще.

Это же был реторический вопрос !!!!!

E>>Недавно был разговор об переносе асма с платформы на платформу....

X>Это экономически не обосновано, как мне кажется. Заниматься такой фигней .

Гы..., имееться ввиду перенос не человеком, а машиной!!!!

E>>Что делать? Выход есть....

X>Какой выход? Насколько я понимаю, 32 разрядный код будет исполнятся на ИА-64 медленно. Или есть какие-то умные конвертеры из машинного кода из х486+ в ИА-64?


Поживём увидим


E>>Вы мне скажите что будут делать программисты, есил тенденция полёта ЯВУ в верх не смениться.....

X>Мда, тогда под программировнаием будет пониматься совсем не то, что сейчас. Нужно будет двигать картинки, наподобие UML диаграмм или еще чего попроще. Тогда все программисты будут сразу становится архитекторами. Но до этого еще относительно далеко. Пока можно развлекаться ловлей суперхитрых багов.

Боюсь что не совсем так....
Вернее так, но не с ООП и процедурным программингом...
Здесь уже нужна новая технология...
И при этом всём... это не значит что низкоуровневое программирование сомнётсья...
Скорее может быть даже наоборот

Здравствуйте Edmond, Вы писали:

E>Да? Ямаха говорите
E>Не знал.... Для меня Ямаха, это не плохие проффессиональные синтезаторы....

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

Здравствуйте Edmond, Вы писали:

X>>Да полно таких, ключевой слово — Windows CE.

E>Ловлю на слове: полно таких... пример Windows CE )))))))))))))))))))))))))
E>Вам не смешно?

Нет не смешно. Ло знакомства с WinCE я считал, что Win32 — это читстый Wintel, и всякие там альфы — это так, детские игрушки. Однако же основное подмножество Win32, подкрепленное библиотеками запросто позволяет писать под самые разнообразные платформы. Что самое удивительное, что у вполне работоспособной CE 2.0 были просто мизерные требования к памяти. Это веь не компилятор языка написать и даже не библиотеку перенести. По сути переносимость на уровне ОС, со всем соглашениями. И при этом, ни эмуляции, ни интерпретации некоего p-code здесь и рядом не лежало.

X>>Переносимость — это когда код не требует серьезной переделки, чтобы работаьт где-то еще.

E>Это же был реторический вопрос !!!!!




E>>>Недавно был разговор об переносе асма с платформы на платформу....

X>>Это экономически не обосновано, как мне кажется. Заниматься такой фигней .

E>Гы..., имееться ввиду перенос не человеком, а машиной!!!!

Вот и я к тому: то ли надо писать конвертор кода (реально ли?), то ли эмулятор процессора (с эмулятором среды выполнения на пару). Дядечки с толстыми кошельками скорее заплатят за разработку новой системы с нуля, чем за попытку конвертации больших объемов ассемблерного кода на новые платформы. Потому что понимают, что даже ежели получится, то через пяток лет им опять придется искать парней, которые должны будут писать эмулятор или конвертор под новую платформу...

И я уверен, что эти самые дядечки с толстыми кошельками будут очень внимательно следить, чтобы в новую систему не попала ни одна строчка на ассемблере.


E>Боюсь что не совсем так....
E>Вернее так, но не с ООП и процедурным программингом...
E>Здесь уже нужна новая технология...

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

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

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

Ну а там уже по плану придет Мессия и всех спасет от поголовной безработицы.

E>И при этом всём... это не значит что низкоуровневое программирование сомнётсья...

низкоуровневое программирование останется всегда — хотя вполне возможно, что новые процессоры и другие железки будут целиком и полностью разрабатываться на ЯВУ, а версия компилятора Visual Basic для этих кристаллов будет создаваться как Post-Build Step при создании схемы железки. Но это я так, немножко отвлекся от реальности

Здравствуйте, Hacker_Delphi, Вы писали:

HD>Здравствуйте VladD2, Вы писали:

VD>>А что MMX и SSE компиляторам не доступны?

HD>Насчет MMX и SSE — не знаю. Но я еще не видел компилятора, который перебор массива целых в цикле превращал в конструкцию :
HD>

HD>LOCK REPNE SCASD
HD>

хахахахахах

так писали пять лет назад. это ЖУТКО тормозная инструкция на современных процессорах.
Ибо

1) префиксы — зло, долго декодируются
2) инструкция — CISC, для нёё громоздкая микропрограмма

написать по-тупому

mov esi, src
xor edx, edx
mov eax, val
@l1:
test eax, [esi + edx*4]
inc edx
jne @l1

будет БЫСТРЕЕ

HD>А более быстрого варианта решения задачи прямого перебора массива в памяти я ешшо не встречал
HD>Хотя, возможно, есть еще более наворочаные инструкции процессоров из SSE/SSE2 — я с ними не особо знаком, но и там будет аналог данного алгоритма, а не что-то другое, так что увы других вариантов нет.

да при чём тут SSE ?!! SSE — это векторная обработка (к тому же с низкой точностью). И надо сказать, сильного прироста это поделие не даёт. В итоге оказывается удобнее использовать геометрический процессор какой-ньть GeForce.

HD>Дело в том, что разработчик, имеющий представление о данных, всегда может соптимизировать код (иногда — ТОЛЬКО с применением ассемблера) так, чтобы он работал быстрее, чем то, что нагенерит самый наворочаный компилятор ЯВУ. Увы, но это — так.

HD>Как и многие высказавшиеся я считаю, что ассемблер — это один из последних шагов оптимизации, зато после него уже нет вариантов, да и сомнений в скорости не остается.

HD>Еще одно важное преимущество ассемблера — достаточно малый исполняемый код. Программа, которая будет целиком (и правильно) написана на ассемблере — совсем маленькая программа.

в том то и дело, что на асме (по крайней мере intel-овском) хорошо писать только МАЛЕНЬКИЕ программы

Здравствуйте, WarlockFX, Вы писали:

WFX>Из моих скудных познаний: ассемблер — язык, использующий аббревиатуры, напоминающие англ. язык.
Ну тогда паскаль это вообще литературный английский.
WFX>Так зачем использовать ассемблер сейчас, когда есть куда более удобные языки высокого уровня?? Неужели только из-за быстродействия?! И это в эпоху пентиумов4?
Ну вопервых не всегда можно обойтись языком высокого уровня

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

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