Так это главное, конкретный стек можно самому или на работе выучить. Скажем, сам я по образованию физик, основные языки C/C++, при этом C изучал в основном в школе, плюсы - что-то читал сам, реально писать начал только на работе.
Страничка в браузере на моём 4" телефоне вполне адекватна, смысла в приложении не вижу. Правда, я не пользуюсь онлайн навигацией - заранее изучаю местность, там уже иду по памяти.
PS Глянул на телефоне новый дизайн - чёрный текст на сером фоне никак не способствует читаемости названий улиц.
Фактически образование - это получение новых знаний
И получение умения потом самостоятельно получать дополнительные новые знания. Несколько лет в институте с курсовыми и дипломом этому способствуют, несколько месяцев на курсе - не особо, скорее просто дадут какие то конкретные знания/умения. Кроме этого, на коротких курсах часто могут опустить базовые вещи (скажем, просто рассказать про абстрактные вектора/мапы без объяснения, как оно реализуется), без которой сложно понять, как аналогичные вещи будут работать в других условиях (другой ЯП, native/managed и т.п.). Так что научиться генерить тонны кода на конкретном ЯП/фреймворке по чёткому ТЗ на курсах, пожалуй, можно, но понять как оно работает и создавать что-то реально новое - вряд ли.
Ладно хоть в браузере этого нет ) В основном смотрю карты с лаптопа (с подключенным монитором); на телефоне разок попробовал поставить приложение, увидел что на саму карту там места на экране остаётся меньше, чем в браузере, снёс.
С кодировкой да, можно было поиграться, бинарной совместимости всё равно нет - но, возможно, тогда не видели смысла что-то делать. Так то кодировка с переменной длиной даёт возможность уменьшать размер кода, но по факту на x86 минимальная длина не у самых частых опкодов, а у самых древних.
Подозреваю, что о полуавтоматическом портировании ассемблерного кода с 8086 тоже думали. Ну и поддерживать его выполнение в 16битных режимах было бы сложнее при более заметных отличиях 32битной ISA. С 32->64 примерно то же самое.
Стало иметь меньшее значение, когда началось массовое кэширование DRAM.
Есть ещё другое - инструкции фиксированного размера легко раздекодировать параллельно, так что это не тормозит пайплайн; в x86 же кроме ухищрений с декодером придумали ещё uop кеш и прочее LSD.
На моделях уровня от лаптопа или толстого embedded - да, наверняка хотя бы частично сделано.
Да, я скорее про серверные думаю )
Если таких команд очень мало от общего числа, то логику можно упростить до трекинга полного комплекта флагов.
Но мы же про оптимизацию для кода типа арифметики произвольной длины, если там в горячем цикле как то отдельно используются перенос и переполнение, лучше рассматривать отдельно.
Расширить формат команды может быть сложнее и вреднее на будущее, чем иметь служебный регистр.
А если в кодировке оставить один dst, но писать при этом ещё и в регистр dst +1 (и возможно в следующие) ?
Подавляющее большинство случаев (опять же, навскидку, 99% и больше) условных действий по флагам идут сразу после сравнений, следующей командой.
Собственно, поэтому на современных процах с флагами compare+branch обычно фьюзится в одну микроинструкцию, эквивалентную бранчу от MIPS/RISC V. Так что отказ от флагов позволяет выкинуть соответствующую логику.
Ну и самим регистром флагов, просто ещё одним служебным.
Это уже не так просто, нужна логика для тракинга зависимостей между инструкциями по отдельным битам - ну и операционка должна детектить такое расширение и сохранять/восстанавливать дополнительный регистр, как с векторами. Проще в этих adc/sbc задействовать дополнительный обычный регистр для флага переноса.
PS Поигрался на godbolt - простое сравнение (a + b) < a gcc для x86 компилирует в проверку флага, а вот описанная формула для знаковых чисел как то вообще уходит. Похоже, из за того, что unsigned overflow - UB, но как тогда этот код на переносимом C/C++ написать - разве что работать с числами как с беззнаковыми, явно проверяя старший бит. Что то такое получается, но как то кривовато.
Так это главное, конкретный стек можно самому или на работе выучить. Скажем, сам я по образованию физик, основные языки C/C++, при этом C изучал в основном в школе, плюсы - что-то читал сам, реально писать начал только на работе.
Страничка в браузере на моём 4" телефоне вполне адекватна, смысла в приложении не вижу. Правда, я не пользуюсь онлайн навигацией - заранее изучаю местность, там уже иду по памяти.
PS Глянул на телефоне новый дизайн - чёрный текст на сером фоне никак не способствует читаемости названий улиц.
И потом неожиданно обнаружить, что заметная доля времени уходит на апдейты счётчиков ссылок и прочие не имеющие отношения к целевой задаче вещи.
И получение умения потом самостоятельно получать дополнительные новые знания. Несколько лет в институте с курсовыми и дипломом этому способствуют, несколько месяцев на курсе - не особо, скорее просто дадут какие то конкретные знания/умения. Кроме этого, на коротких курсах часто могут опустить базовые вещи (скажем, просто рассказать про абстрактные вектора/мапы без объяснения, как оно реализуется), без которой сложно понять, как аналогичные вещи будут работать в других условиях (другой ЯП, native/managed и т.п.). Так что научиться генерить тонны кода на конкретном ЯП/фреймворке по чёткому ТЗ на курсах, пожалуй, можно, но понять как оно работает и создавать что-то реально новое - вряд ли.
Да это практически ко всему относится, на какую нибудь кафешку на телефоне заметно сложнее кликнуть, чем на гуглокартах.
Меня тогда жаба душила даже на б/ушный Пальм разориться )
Ладно хоть в браузере этого нет ) В основном смотрю карты с лаптопа (с подключенным монитором); на телефоне разок попробовал поставить приложение, увидел что на саму карту там места на экране остаётся меньше, чем в браузере, снёс.
Перегрузил страничку - дорого всё ещё жёлтые.
PS Таки долетело изменение. Насчёт цветов - непривычно, но ладно
Это точно глаза режет.
В прикладном коде. А так то ещё MMIO есть.
IT образование - это всё таки кафедры в ВУЗах, а не какие то курсы/школы...
С кодировкой да, можно было поиграться, бинарной совместимости всё равно нет - но, возможно, тогда не видели смысла что-то делать. Так то кодировка с переменной длиной даёт возможность уменьшать размер кода, но по факту на x86 минимальная длина не у самых частых опкодов, а у самых древних.
Подозреваю, что о полуавтоматическом портировании ассемблерного кода с 8086 тоже думали. Ну и поддерживать его выполнение в 16битных режимах было бы сложнее при более заметных отличиях 32битной ISA. С 32->64 примерно то же самое.
Материковые китайцы в те времена осилили клон 6502?
Не факт что доживём ) Пока проблем нет, при том что расширений и там и на аналогичном RISC V уже более чем дофига.
Есть ещё другое - инструкции фиксированного размера легко раздекодировать параллельно, так что это не тормозит пайплайн; в x86 же кроме ухищрений с декодером придумали ещё uop кеш и прочее LSD.
Да, я скорее про серверные думаю )
Но мы же про оптимизацию для кода типа арифметики произвольной длины, если там в горячем цикле как то отдельно используются перенос и переполнение, лучше рассматривать отдельно.
А если в кодировке оставить один dst, но писать при этом ещё и в регистр dst +1 (и возможно в следующие) ?
Собственно, поэтому на современных процах с флагами compare+branch обычно фьюзится в одну микроинструкцию, эквивалентную бранчу от MIPS/RISC V. Так что отказ от флагов позволяет выкинуть соответствующую логику.
Это уже не так просто, нужна логика для тракинга зависимостей между инструкциями по отдельным битам - ну и операционка должна детектить такое расширение и сохранять/восстанавливать дополнительный регистр, как с векторами. Проще в этих adc/sbc задействовать дополнительный обычный регистр для флага переноса.
PS Поигрался на godbolt - простое сравнение (a + b) < a gcc для x86 компилирует в проверку флага, а вот описанная формула для знаковых чисел как то вообще уходит. Похоже, из за того, что unsigned overflow - UB, но как тогда этот код на переносимом C/C++ написать - разве что работать с числами как с беззнаковыми, явно проверяя старший бит. Что то такое получается, но как то кривовато.
В основном в любом случае нужны были приложения/игрушки от серьёзных производителей, скорее всего они в подписанном виде везде лежали.
А возможно просто софт по фанатским сайтам в основном ходил подписанный.
Да как то не надо.