На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS
msm.ru
! Перед отправкой сообщения внимательно прочтите правила раздела!!!
1. Запрещается обсуждать написание вирусов, троянов и других вредоносных программ!
2. Помните, что у нас есть FAQ раздела Assembler и Полезные ссылки. Посмотрите, возможно, там уже имеется решение вашего вопроса.

3. Настоятельно рекомендуем обратить особое внимание на правила форума, которые нарушаются чаще всего:
  3.1. Заголовок темы должен кратко отражать её суть. Темы с заголовками типа "Срочно помогите!" или "Ассемблер" будут отправляться в Корзину для мусора.
  3.2. Исходники программ обязательно выделяйте тегами [code]...[/code] (одиночные инструкции можно не выделять).
  3.3. Нежелательно поднимать старые темы (не обновлявшиеся более года) без веской на то причины.

Не забывайте также про главные Правила форума!

Добро пожаловать и приятного вам общения!!! ;)
 
Модераторы: Jin X, Qraizer
Страницы: (5) 1 [2] 3 4 ... Последняя » все  ( Перейти к последнему сообщению )  
> Как часто вы используете ассемблер?
   
Как часто и где вы используете ассемблер?
Гости не могут просматривать результаты голосования.
Гости не могут голосовать 
    Цитата Hsilgos @
    Задумал я написать минимальную программу

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

    Сам постоянно пишу на асм-е, но только для микроконтроллера. При этом заявить, что знаю ассемблер - ну никак не могу, ибо их - ассемблеров - уж больно много, я знаю более-менее хорошо только для одной(!) линейки мк (а для 286 читаю, ну мелочь какую написать, и то с трудом; старшие - вообще тёмный лес).
    К сожалению - сколько процессоров, столько и ассемблеров. И каждый практически с 0 изучать надо - ведь это по сути не изучение языка, а изучение процессора. Расточительная трата времени.
      Цитата Adil @
      Цитата Hsilgos @
      Задумал я написать минимальную программу

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

      А думаешь нет? Уже пару лет поддерживаю пару программ, работающих на смешных компах, еще первые пни, с винтами на 125 и 500 Мб. Основное место занимают базы данных и система, оставляя программе мизер. Тут выбора нет, только асм и возможен.
      Несколько раз кодил аналоги 8086, с 4-256Кб памяти.
      Сейчас экспериментирую с интерфейсом, расчитанным на несколько Кб памяти, пытаясь сделать в графике :) если получится то срублю неплохие бабки.
      Так что еще есть где развернуться, старого барахла осталось немало, а выкидывать его не торопятся :)
        Цитата AndNot @
        Несколько раз кодил аналоги 8086, с 4-256Кб памяти.
        Сейчас экспериментирую с интерфейсом, расчитанным на несколько Кб памяти, пытаясь сделать в графике :) если получится то срублю неплохие бабки.
        Ну это сродни МК, тут спору нет - асм рулит.
        Цитата AndNot @
        А думаешь нет? Уже пару лет поддерживаю пару программ, работающих на смешных компах, еще первые пни, с винтами на 125 и 500 Мб. Основное место занимают базы данных и система, оставляя программе мизер. Тут выбора нет, только асм и возможен.
        ...
        Так что еще есть где развернуться, старого барахла осталось немало, а выкидывать его не торопятся
        Ну так это от бестолковости заказчиков - свои же деньги считать не умеют - купить нормальный комп, программисту денег заплатить меньше - еще в большом плюсе останутся.
          Ты не понял :) Те устройства, на 8086, пошли в серию, так что экономия очень значительна ;) Какие, говорить не буду, но одно из них используется повсеместно , хотя я был одним из многих, но все равно приятно осознавать, что жизнь прожил не зря ;)
            Цитата semiono @
            Но удивлён когда продвинутые программисты выбирают что-то другое...
            Поверь, станешь продвинутым - будешь удивляться, вспоминая вот эту свою точку зрения. Сам такой был, знаю. После реализации DMPI-хоста, соответствущего спецификации 1.0 и навешивающегося на любой уже имеющийся, соответствующий спецификации 0.9, интересы сместились от виртуозности управления процессором в сторону виртуозности управления компилятором. Оказалось, это не менее увлекательно.
            Цитата andriano @
            На ЯВУ можно (и нужно!) написать все то же самое, что и на ассемблере (за исключением оптимизации средствами MMX, SSE, etc.), ...
            Не правда. Нормальные копиляторы уже давно это делают, а Intel, так та вообще хочет забыть нафиг FPU как страшный сон и заставить всех юзать исключительно SSE2 и выше...
            Цитата leo @
            ...ЯВУ-компиляторы неплохо оптимизируют целочисленные операции и, мягко говоря, неважно FPU. Видимо из-за сложностей работы со FPU-стеком явушные реализации грешат ненужными загрузками\выгрузками промежуточных FPU-вычислений в память и многочисленными обменами регистров fxch
            ...в основном как раз из-за архитектурных недостатков FPU. Но ненужные "загрузки/выгрузки" и "многочисленные обмены регистров fxch" не есть дезоптимизация. Обмены, например, как раз и позволяют обойти архитектурное неудобство FPU, связанное с его стек-ориентированностью и позволяет спараллелить исполнение нескольких FPU-инструкций, убрав зависимость по ST(0), лишь бы исполнительных блоков у процессора хватило. "Ненужные" же операции с памятью могут выполнять роль SSEёвых PREFETCH-ей. Не стоит спорить с оптимизатором без необходимости.
            Цитата AndNot @
            Вспомнить можно много чего, например мониторинг производительности, через регистры MSR и CESR Или возьми такую область, как дебаггеры. Только на асме возможно легко и просто кодить работу с отладочными регистрами. Только на асме можно сделать обработчики исключений процессора. Только на асме можно реализовать нормальное переключение задач. Да много чего невозможно на ЯВУ...
            Я как-то поспорил на много пива, что смогу написать DOSовый драйвер устройства только на C++ без капли ассемблера. Выиграл. Там много чего было, проще сказать, чего аппаратного я не делал, не прибегая к ассемблеру. На "безасмовом" Паскале писал DSP-библиотеку для записи/проигрывания через SB в фоне, включая SB16. И IRQ там были, и DMA, как же без них... Ну а VxD без ассемблера через несколько лет уже никого бы не удивило.
            Вот чего действительно нельзя сделать без ассемблера, так это завязанного на архитектурные детали процессора, которым компилятор просто не научен. В частности это то, что я не покрасил. Многозадачность, например, как семестрования констрольная была сделана исключительно на переключении стеков, а вместе с ними и сохранённых контекстов CPU, что делалось единственной Борланд С++ной строкой _BP = task[targetsIndex].basePtr; внутри обработчика IRQ0, естественно написанного тоже без ассемблера. Препод тоже долго не мог поверить, что ассемблер для этой задачи не нужен. Когда убедился, учиться остальные полтора года у него стало легче. :P Так что, учите матчасть, то бишь возможности ваших компиляторов: никогда не знаешь, в чём и когда это может помочь. Знатоков ассеблера хватает, а работодателю зачастую не они нужны, а профи-виртуозы, способные выжать максимум из того инструмента, что есть, и знание ассемблера - всего лишь одна и не самая важная составляющая.
            Цитата AndNot @
            Вспомнилось две игрухи, первая на Си, вторая на Паскале. Обе - шутеры, почти одинаковы (во втором спецэффекты более продвинутые). Но вторая на 70% состояла из асма. В результате - вторая работала более гладко, нежели первая, даже при вдвое большем разрешении экрана и большем количестве спецэффектов. Первая была - знаменитая Quake, а вот вторая - Chasm: Shadow The Rift А казалось бы, подумаешь ерунда, какой то там FPU.
            Насколько я помню, ID как раз Quake I выпустила как первую игру, которой действительно требовался FPU. И, показав, что без FPU игровая индустрия дальше будет всё меньше и меньше обходиться, чуть не убила этим MMX. А AMD со своим 3DNow! резво поднялась в рейтингах. А казалось бы - всего-то одна-единственная операция деления, тщательно оптимизированная по тактам под Pentium, чтобы исполняться максимально параллельно с CPU. Не знаю, насколько кривили душой Кармаки, но по их заявлениям перспективную коррекцию текстур с шагом хотя бы в 16 пикселов нереально реализовать без деления, которое можно было сделать целочисленным, т.е. в формате с фиксированной точкой, но хоть FPU и чуть медленее, зато параллелится с CPU. И кстати, FPS был выше даже на менеечастотных Pentium по сравнению с более высокочастотными AMD и Cyrrus. Сам видел - Pentium 120 делал почти вдвое CyrrusLogic 166 - 24 vs 14 (!) Потому как Intel очень хорошо поработала над тактами FPU у Pentium 90 и выше.
            Что касается Chasm - не знаю; не видел, не играл, не слышал комментариев и откликов. Одно могу сказать: оптимизаторы в то время у компиляторов были не весть бог какие, поэтому в то время многие могли прилично поднять производительность своих приложений, применяя много ассемблера. Вот только интересно, почему в таком случае не написать, что "вторая написана на ассемблере с ~30% Паскальных вставок"? :D И прокоментить временем и стоимостью её разработки. Прям здесь и сейчас могу сказать, что свои продукты ID выпускает для множества платформ, включая приставки, так что широкое применение ассемблера в её продуктах есть непозволительная роскошь.
            Цитата Adil @
            Вот, боюсь, большинство ассемблеровщиков и могут привести как аргумент подобные извращения. На практике часто встречаются такие задачи - минимальный по размеру ехе-шник? Очень уж это похоже на исскуство ради исскуства.
            Я могу позволить себе сделать такое сравнение? Есть мастер, у которого на вооружении цифровой анализатор, паяльная станция с вытяжкой, микроскопом и манипуляторами, анлим для качания мануалов и серфигну по форумам итп. Рядом с ним сидит ещё один мастер, работающий паяльником, простым оловом и канифолью, пробниками с питанием от батареек, сапожным ножиком для зачистки проводов и проводочков, целой библиотекой печатной и ксерной документации и тоже тп. При этом делают одинаковую работу. Вариантов три. Либо первый - зарабатывает больше, потому что работает быстрее, и вызывает у клиентов большее доверие. Либо без разницы, потому что услуги второго оцениваются выше. Либо они - одна команда и весь заработок делят поровну, просто каждый занимается своим делом, и каждый обращается к услугам другого по мере необходимости.
            Вот ещё одно сравнение: есть люди, которые могут самостоятельно собрать автомобиль из отдельных деталей, а то и построить самолёт. Они достойны уважения и признания, и они их находят. Но в серию их шедевры не идут, вместо этого их идеи покупают компании, щедро за это вознаграждая. Вот только потом о них никто как правило не знает, а знают ту компанию, которая запустила серию. В общем, я за реализм и против фанатизма.
            Одни с годами умнеют, другие становятся старше.
              Цитата Qraizer @
              Не правда. Нормальные копиляторы уже давно это делают
              Ну уж покажи нам грешным, как нормальные компиляторы юзают MMX ;) Насколько эффективно они юзают SSE? Не так давно замеры проводили. При желании можно без напрягов обставить любой компилятор Cи.
              Цитата Qraizer @
              а Intel, так та вообще хочет забыть нафиг FPU
              Хотеть не вредно, но бесполезно. Почти все задачи, с вещественной арифметикой, предпочтительнее выполнять на FPU, он еще быстрее SSE ;) И даже там, где можно применить преимущества SSE, еще не факт, что FPU окажется медленнее.
              Цитата Qraizer @
              Я как-то поспорил на много пива, что смогу написать DOSовый драйвер устройства
              Непонял, при чем здесь обработчик исключений и дос-дрова? :wacko:
              Цитата Qraizer @
              На "безасмовом" Паскале писал DSP-библиотеку для записи/проигрывания через SB в фоне, включая SB16
              Встречал подобное. Но использовать никогда не стремился, были лучшие аналоги, на асме ;) И работают стабильнее и ресурсов меньше кушают. Вот это и есть наглядный пример, где не стоит использовать ЯВУ ;)
              Цитата Qraizer @
              Ну а VxD без ассемблера через несколько лет уже никого бы не удивило.
              Еще раз повторяю - вин-дрова не являются низким уровнем. Вот когда ты делаешь:
              ExpandedWrap disabled
                        sidt    idt_tab
                        mov     edi,[idt_tab.idt_addr]
                        add     edi,6*8
                        ; сохраняем адрес предыдущего обработчика
                        movzx   eax,[edi].int_hi_offs
                        shl     eax,16
                        mov     ax,[edi].int_lo_offs
                        mov     [OldIntOfs],eax
                        movzx   eax,[edi].int_sel
                        mov     [OldIntSel],ax
                 
                        cli
                        mov     eax,OFFSET32 NewInt06
                        mov     [edi].int_lo_offs,ax
                        shr     eax,16
                        mov     [edi].int_hi_offs,ax
                        mov     eax,cs
                        mov     [edi].int_sel,ax
                        mov     [edi].int_attrib,8E00h
              то только тогда и начинается кодинг на низшем уровне. Т.е. когда ты осознанно отказываешься от kernel-api (некорректный термин, но ты меня понял), когда твой драйвер работает без помощи системы, когда ему вообще до фонаря, под какой системой он находится. Это и называется низкоуровневым программированием. На ЯВУ здесь не развернуться, они для этого не приспособлены. Более того, чем быстрее драйвер отдаст управление системе, тем лучше, поскольку работает он с отключенными прерываниями и не всегда их можно включить до завершения.
              Цитата Qraizer @
              была сделана исключительно на переключении стеков
              Эти средства есть и в Паскале. Но я имел в виду не липовую многозадачность, а аппаратную. Здесь тебе Борланд не поможет ;)
              Цитата Qraizer @
              Насколько я помню, ID как раз Quake I выпустила как первую игру, которой действительно требовался FPU
              Прикол в другом. Обе игрухи использовали FPU, но в Quake его юзал компилятор, а в Чесме вся работа с ним была написана на асме. Отсюда и такие результаты - игруха на Паскале легко сделала игруху на Си :D Хотя общепринято мнение, что на Паскале серьезных игр не пишут.
              Цитата Qraizer @
              И, показав, что без FPU игровая индустрия дальше будет всё меньше и меньше обходиться, чуть не убила этим MMX
              Неужели? Квака вышла задолго до появления MMX. А чуть не загнулась эта технология по другим причинам - отсутствие программистов, знающих ассемблер, поскольку компиляторы ЯВУ не умели юзать эту технологию. Да и сейчас самостоятельно не умеют и еще меньше вырастает программистов, способных освоить эту технологию - они предпочитают уже готовенькое.
              Цитата Qraizer @
              Вот только интересно, почему в таком случае не написать, что "вторая написана на ассемблере с ~30% Паскальных вставок"?
              Дык ведь каркас то и был на паскале :D А запомнилась игруха по одной причине - она была последней, с таким количеством асма. Да и движок был превосходный. Можно было отстрелить руки, ноги, головы (прикольно было оторвать обе руки и смотреть, как монстр пытался бить тебя головой :lol: ), был реализован даже полупрозрачный дым от взрывов (и это в 8-ми битной графике!), полупрозрачная вода, тени, разрушающиеся стены(где по сценарию разрешено было). В общем движок был лучшим в ДОСе, а по скорости - просто превосходный, я на Pentium 100 проходил, под видеорежимом 400x300, а на 150-м - 640x400. И это без акселератора. Ну и приятно, что этот шедевр выпустили украинские программисты :wub: Советую скачать да посмотреть. Найдешь на любом сайте, со старыми играми.
              Цитата Qraizer @
              Я могу позволить себе сделать такое сравнение?
              Сравнения никогда не бывают точными <_<
                А AndNot прав. Асм дает гораздо больше возможностей. Например, если компилятор ЯВУ что-то не поддерживает (MMX, 3d-now и т.д.), то у программиста связаны руки. Здесь поможет только асм. Все эти новые модификации и интерфейсы появляются каждый год, а компиляторы под все новшества писать не успевают. (И кстати, на чем пишут компиляторы ЯВУ?).
                Чем больше мы будем работать на ЯВУ, тем сильнее мы привязываемся к определенной ОС, в особенности Windows (см опрос "Ваше мнение о монополиях").
                  Цитата Qraizer @
                  Я как-то поспорил на много пива, что смогу написать DOSовый драйвер устройства только на C++ без капли ассемблера. Выиграл.

                  А как ты заголовок драйвера сделал? (тот из которых список формируется).
                  Взял какую нибудь либу или как? В DOS'овский .sys ни один линкер собирать не умеет.
                  А набитый кем-то заголовок и скомпилированный в obj который потом линкуется с hll кодом - это не честно.
                  Да, тело драйвера можно написать допустим на Си, но заголовок ты не сформируеш.

                  Цитата Qraizer @
                  На "безасмовом" Паскале писал DSP-библиотеку для записи/проигрывания через SB в фоне, включая SB16. И IRQ там были, и DMA, как же без них...

                  Это мягко говоря не совсем правда. И что ты писал для посылки EOI допустим?
                  port[$20]:=$20; или outportb(0x20,0x20);
                  Это по сути и есть использование ассемблера, только завёрнутого в функцию.
                  Это ведь не стандартизированные средства, а заточенные под конкретную ОС.
                  Под Windows допустим ты даже в драйвере не напишеш outportb() - потому что её просто нет.

                  Цитата Qraizer @
                  что делалось единственной Борланд С++ной строкой _BP = task[targetsIndex].basePtr; внутри обработчика IRQ0

                  Опять же - это завуалированное использование ассемблера.
                  Возьми любой другой компилятор (не Borland) и попробуй собери.

                  Цитата Qraizer @
                  ...в основном как раз из-за архитектурных недостатков FPU. Но ненужные "загрузки/выгрузки" и "многочисленные обмены регистров fxch" не есть дезоптимизация.

                  Нормальная у fpu архитектура, просто компиляторы не заточены использовать все восемь регистров.
                  Я вложенности fpu стека выше 3-4 ниразу не видел.

                  Цитата Qraizer @
                  Не правда. Нормальные копиляторы уже давно это делают, а Intel, так та вообще хочет забыть нафиг FPU как страшный сон и заставить всех юзать исключительно SSE2 и выше...

                  И вот с последствиями этого я сейчас борюсь :)
                  Пишу эмулятор SSE, так как CPU у меня AMD, и 3DNow! есть, а SSE нету.
                  А в одной программе Adobe используется SSE, причём даже не проверяется его наличие. И конечно программа падает.
                  А всё потому что люди собрали с оптимизацией для P4, по-моему intel c compiler.
                  При этом 90% SSE кода выглядит так:
                  ExpandedWrap disabled
                    movss xmm0,[mem1]
                    movss [mem2],xmm0

                  Спору нет, без SSE тут никак нельзя.
                  Вот ещё код оттуда же:
                  ExpandedWrap disabled
                    fstp  [var1]
                    movss xmm0,[var1]
                    movss [var2],xmm0
                    fld   [var2]
                  Интересно, что мешало сделать просто
                  ExpandedWrap disabled
                    fst   [var1]
                    fst   [var2]

                  В общем компиляторы очень часто SSE суют без особой на то необходимости.
                  Просто из-за того что это ещё дополнителных 7 регистров к которым в отличии от fpu можно обращаться напрямую.

                  Лично я много пишу на Си, но точно так же много и на ассемблере.
                  И те вещи которые легче писать на ассемблере, я на нём и пишу (в основном работа с оборудованием и т.д.).
                  Но GUI к примеру писать на ассемблере я большого смысла не вижу, хотя опять же дело привычки.
                  Если GUI на WinAPI, по разницы практически никакой.
                    Цитата Qraizer @
                    Не стоит спорить с оптимизатором без необходимости

                    Во-во :D
                      Цитата AndNot @
                      Ну уж покажи нам грешным, как нормальные компиляторы юзают MMX Насколько эффективно они юзают SSE? Не так давно замеры проводили. При желании можно без напрягов обставить любой компилятор Cи.
                      Что значит, грешным? Ты что, рассчитываешь, что компилятор адекватно выполнит интерполяцию твоей цели, базируясь на исходниках, и сам изменит алгоритм для лучшего соответствия SIMD-модели? Посмотри в хидеры к Intel Compiler, чтобы приблизительно иметь представление о что, как програмить на ЯВУ сразу в SIMD-модели. Когда ты это делаешь ассемблером, тебя же это не удивляет. Хотя cl и icl/icc уже умеют делать выводы на основе результатов разворачивания циклов, но это у них получается не очень, так что не удивительно, что их несложно обставить, если ты написал алгоритм в классическом стиле, подразумевая SIMD. Будь всё-таки объективен.
                      Цитата AndNot @
                      Почти все задачи, с вещественной арифметикой, предпочтительнее выполнять на FPU, он еще быстрее SSE
                      А ты сравнивал? FSIN например, работает медленее, чем intelовская sin(), а она в свою очередь юзает невекторные SSE2 инструкции. У меня получились отношения (std::sin / asm's FSIN / Intel's sin) примерно такие: 129 / 90 / 42. А выигрыш получается хотя бы за счёт бОльших возможностей оптимизации из-за нестековой архитектуры. Желание же Intel отказаться от FPU вообще вполне объяснимо - бакэнд оптимизация для FPU нетривиальна и сильно отличается по своим принципам. Ну а то, что это бесполезная надежда, я и не спорю.
                      Цитата AndNot @
                      Непонял, при чем здесь обработчик исключений и дос-дрова?
                      Не при чём. А с чего ты взял, что они тут должны иметь друг к другу какое-то отношение? При чём были возможности ЯВУ против возможностей ассемблера. Оказалось, что они адекватны. Исходник привести к сожалению не могу, потерялся лет семь назад, но могу сказать, что писалось на Borland C++ 3.1, сорец пестрил #pragma codeseg, отключались библиотеки (правда, некоторые обджики вырезались из либ и подлинковывались явно), юзалась meduim модель и собиралось это всё не в IDE, а make-ом явно указанными командными строчками. cppasm, это и тебе тоже ответ. Не скажу, что это было удобнее, чем ассеблером, но писалось это на спор и тем было доказано, что это возможно.
                      Цитата AndNot @
                      Встречал подобное. Но использовать никогда не стремился, были лучшие аналоги, на асме И работают стабильнее и ресурсов меньше кушают. Вот это и есть наглядный пример, где не стоит использовать ЯВУ
                      Тебе прислать, что получилось? 8-) Этот сорец у меня остался. Сам сделаешь выводы на предмет скорости, ресурсоёмкости и производительности. TPUшка 8,5Кб, минимальный размер SB буфера 1Кб. Было написано за пару дней. Даже при компиляции под DPMI работало на ура, на что понадобилось ещё с полчаса. Зато даже при компиляции под Windows Target прекрасно работало как easyWind, если предварительно в винде прибить дрова SB, чтоб не мешали юзать DMA и IRQ. Правда, под DMPI и Win буфер в 1Кб был уже маловат. Давай посмотрим, как ты всё это сделаешь на ассемблере, и насколько это в целом будет выгоднее Паскаля.
                      Цитата AndNot @
                      Еще раз повторяю - вин-дрова не являются низким уровнем. Вот когда ты делаешь: ...
                      Я б на твоём месте этот фрагмент бы не писал... Во-первых, на предмет заюзывания архитектурных особенностей, я вроде бы высказывался, или ты читаешь "по-диагонали"? На предмет всего остального, что в цитате скрыто под ..., то в твоём понимании термина "низкий уровень" двайверы вообще отсутствуют. Так и писали в DOS, у которой фактически единственное, что было представлено как OS API - это доступ к файловой системе. Или ты считаешь нормальным сегодня использовать устаревшие технологии проектирования вычислительных систем? Во всех остальных случаях игнорировать kernelAPI - смириться с перманентным апдэйтом своего шедевра чуть ли не с каждым сервис-паком, а то и просто заплаткой. Не спорю, Ягуары очень хорошие машины, только дорогие. Самое то, чтоб повыпендриваться. Ну и наконец собственно ассемблерный фрагмент, во-первых, ничего не доказывает, потому что кроме первой инструкции всё это перекладывается на любой язык, даже Бейсик, во-вторых написан с нарушением принципов проектирования надёжного системного кода.
                      Цитата AndNot @
                      Но я имел в виду не липовую многозадачность, а аппаратную.
                      Переключение по прерыванию от таймера есть липовая многозадачность? :o Не смеши. Если ты имел в виду многозадачность на уровне task state segments, то вынужден разочаровать: во-первых, они многими ОСами и не используются; во-вторых, кроме начального пинка в лице LTR где-то сразу после перехода в PM, всё остальное на каких-нибудь Сях пишется куда как проще - сплошные структуры, битовые поля и адресация через массивы дескрипторов и страниц.
                      Цитата AndNot @
                      Прикол в другом. Обе игрухи использовали FPU, но в Quake его юзал компилятор, а в Чесме вся работа с ним была написана на асме. Отсюда и такие результаты - игруха на Паскале легко сделала игруху на Си Хотя общепринято мнение, что на Паскале серьезных игр не пишут.
                      Твой тезис противоречит заявлению Кармака. Уж извини, но ему я скорее поверю. А остальное - ты не со мной споришь, я обратного не утверждал. Только говорить о том, что игруха написана на Паскале, согласись, в данном случае значит передёргивать.
                      Цитата AndNot @
                      Квака вышла задолго до появления MMX. А чуть не загнулась эта технология по другим причинам - отсутствие программистов, знающих ассемблер, поскольку компиляторы ЯВУ не умели юзать эту технологию.
                      Как раз из-за того, что задолго, чуть и не убила. MMX - это целочисленный SIMD. Intel на то и рассчитывала, что это станет хорошим подспорьем, так как MMX превращает её процессоры в эдакие DSP. Вот эта технология наконец-то выходит, ждали её не один год (кстати, а чего там было столько времени делать?), а программисты вдруг выясняют, что для float-ов она не предназначена. И кому на фиг она нужна, чтобы её изучать, если губы уже раскатаны под мощные 3D алгоритмы, где без плаваюшей точки уже туговато, это не спрайтиками экран текстурировать. Так что программистов хватало, не хватало желания. Плюс, знать ассемблер одно, а научиться эффективно пользоваться SIMD - это другое. А вот 3DNow! вызвал нужный резонанс, потому как float.
                      Цитата AndNot @
                      ...Советую скачать да посмотреть. Найдешь на любом сайте, со старыми играми.
                      Скока весит? Вполне возможно, что и скачаю. В своё время не думал, что Duke Nukem увлечёт, но начал играть, вполне себе ничего оказалось. Не эффекты главное, хотя куда же без них, конечно, а антураж. Дум 3 тому подтвеждение.
                      Цитата schooler @
                      А AndNot прав. Асм дает гораздо больше возможностей... Чем больше мы будем работать на ЯВУ, тем сильнее мы привязываемся к определенной ОС...
                      Я и не говорю, что AndNot не прав. Он просто черезчур консервативен, а кроме того, утверждает, я не прав я <_< . У асма больше возможностей? Безусловно. А у ЯВУ меньше, да? А ты знаешь, каковы возможности твоей реализации С++, чтобы утверждать, что конкретно она тебе позволит сделать, а что не сможет? Возможности Borland C++ 3.1 и Borland Pascal 7.0 я обрисовал.
                      Последняя фраза меня просто убила. Весь мир считает, что ЯВУ во-вторую очередь после удобства использования предназначены для того, чтобы такой завязки не было, а тут нА тебе, оказывается не завязан как раз ассемблер. :D Предалагаю это открытие опубликовать и запатентовать.
                      Цитата cppasm @
                      И что ты писал для посылки EOI допустим?
                      port[$20]:=$20; или outportb(0x20,0x20);
                      Это по сути и есть использование ассемблера, только завёрнутого в функцию.
                      Это ведь не стандартизированные средства, а заточенные под конкретную ОС.
                      Под Windows допустим ты даже в драйвере не напишеш outportb() - потому что её просто нет.
                      Ну и что, что закамуфлированный? Во-первых, если так рассуждать, то любое использование ЯВУ есть закамуфлированное использование ассеблера, а ассемблер - закамуфлированный объектный код. Во-вторых, ничего подобного, это стандартные массивы, если заглянуть в хелп. И как часть языка, будет работать везде, где язык позволяет. И под Виндой тоже. И работало, кстати.
                      "стандартизированные средства" - умоляю. Это что же получается, я утверждаю, что некая железячная задача может быть решена без ассемблера, а меня попрекают, мол, это будет непереносимо? Нелогично. Задача программировать SB сама по себе является слабопереносимой, потому как в такой формулировке завязана на железо, что как раз и представляет собой её ценность в диалоге "асм против ЯВУ". А под Windows в драйвере я напишу WRITE_PORT_UCHAR(), и будет мне счастье. Причём работать будет даже на Alpha-е и MIPS, которые не имеют отдельного адресного пространства ввода/вывода, как x86. Как это будет работать - не моя проблема, а Винды, это она такую гарантию даёт.
                      Цитата cppasm @
                      Опять же - это завуалированное использование ассемблера.
                      Возьми любой другой компилятор (не Borland) и попробуй собери.
                      Опять же нет. Это возможность предоставляется реализацией, и я её использовал. Только и всего. Непереносимо? А юзать ассемблер переносимей? Препод сказал, юзайте BC3.1. Я тут причём? Кстати, сейчас я уже вижу как эту контрольную можно было сделать без непереносимостей, кроме некоторых ограничений на момент переключения. Тогда не видел.
                      Цитата cppasm @
                      И вот с последствиями этого я сейчас борюсь
                      Пишу эмулятор SSE, так как CPU у меня AMD, и 3DNow! есть, а SSE нету.
                      А в одной программе Adobe используется SSE, причём даже не проверяется его наличие. И конечно программа падает.
                      А виноват Intel, что ли? :D Не пользуйся результатами криворуких разработчиков, я вот не пользуюсь. Вообще же, скажешь Intel Compiler-у, мол, хочу SSE, он и заюзает, скажешь, хочу, но мало ли..., он сделает два варианта и поветвится. Куда придётся ветвиться, программа определяет при своём старте.А может ты просто не почитал минимальные системные требования? ;)
                      Следующие примеры из той же оперы. Компилятору позволили, он и заюзал, где посчитал выгодным. Почему выгодным - приведи больше контекста, постараюсь ответить. А можешь посмотреть и отчёты Intel-а. Если его попросить, он столько наотчитывается при компиляции - с неделю будешь изучать и если осилишь, станешь профи в бак-энд оптимизации под её процессоры.
                      Одни с годами умнеют, другие становятся старше.
                        Я - любитель, пишу на асме и С++. Честно говоря больше нравиться на асме :D Но когда читаю объявления о наборе программистов чаще всего приглашают программистов на С++, C# и Java :( Хотя преподаватели говорят что сейчас требуются программисты на асме, но что-то я не встречал таких объявлений, а жаль! :( Нет, и всё же, как не крути, асм не исчезнет! И со "скоростью" асма не поспоришь ;) И к тому же, я думаю, что знание асма, это большой "+" :lol: Наверно уж работодатели это приветствуют! :rolleyes:
                        Первый человек, которого создал Бог, говорил: "Hello World!" и умирал... :)
                          только когда патчу какой нибудь бинарный файл :whistle:
                            Цитата schooler @
                            Чем больше мы будем работать на ЯВУ, тем сильнее мы привязываемся к определенной ОС, в особенности Windows (см опрос "Ваше мнение о монополиях").

                            Ну ладно, согласен, немного погорячился. Но все-таки ЯВУ не позволяют написать что-либо с нуля, а асм позволяет. Я имел ввиду настоящее низкоуровневое программирование без использования функций ОС. ЯВУ сегодня все больше и больше привязаны к ОС или библиотеке типа DirectX или .NET.
                            0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                            0 пользователей:


                            Рейтинг@Mail.ru
                            [ Script Execution time: 0,2149 ]   [ 19 queries used ]   [ Generated: 16.10.18, 10:22 GMT ]