С отсутствием многих плюшек по сравнению с виндой согласен, но это позволяет этому «куску говна» одинаково работать как на устройствах с 64 Мб памяти, так и на десктопах
согласен, но данному способу представления данных уже более 60 лет, он возник, когда не было вообще понимания как передавать данных от операционной системе к программе или от одной программе к другой; и вот это legacy, сегодня выдают за какую-то генеальность
я не имею виду стандарты текстовых форматов - с этим все понятно; разговор про системные данные, которая возвращаются операционной системой посредством виртуальной файловой системы (например, /proc, /sys, /dev и так далее) - программа их получает в текстовом формате, то есть в этом моменте получаем две бесполезные работы: одну выполняет операционная система парсит бинарные данные в текст, а другую принимающая программа, чтобы получить бинарные значения
бинарные форматы проще представлять структурами и работать с ними
система парсит бинарные данные в текстовые, программа читает их, переводит в бинарную форму, если их не много - это полбеды, а если много, то на момент окончания парсинга - они могут быть уже не актуальными или были изменены другим приложением...
Нет, именно Linux Kernel API, а не какой-то POSIX! Например, попробуй найти функцию POSIX pthread_create среди системных вызовов ядра.
Зачем прикладному программисту знать, где операционная система хранит свою информацию? Ради того чтобы показать, что ядро быстро работает? В Linux очень большой объем кода операционной системы перенесен на прикладной уровень (да виде библиотек, но это прикладной уровень)
В реестре Windows програмисту не приходиться самому перебирать "key-value", у реестра свой - API, то есть функции Registry functions. В Linux никогда не будет аналогично реестра, потому что это сметри подобно. Если одна программа карява пропишет свою же информацию в реестре, то это будет смерть всему остальному. Поэтому разработчики Linux принимают единственное правильное решение - нет реестра, нет и никакой отвественности
Как программист Linux - овно с которым приходиться мириться, а что вы хотели от системы которая неизменно несет свою концепцию с 70-х годов (пардон, с 90-х). Кроме Linux Kernel API никакого API больше нет. Тотальная "нелюбовь" к бинарным форматам приводит к тому, что значимая часть любой программы (ну, кроме, 'Hello world!') это парсер текстовой информации в бинарный и наоборот. Ах, ну да, есть же множество бибилотек для работы с системой. С бибилотеками отдельная песня: чаще всего не работают даже заявленные функции; накладываются всякие ограничения и недоделанность функционала. Одним словом отсутствует автоматизация работы с операционной системой и приложениями, сплошной ручной труд...
В США в национальном парке «Секвойя» вообще перестали тушить пожары, когда выяснилось, что источником пожаров стали сами секвойи. В жару деревья начинают интесивно смолить и загорается, для самое дерева пожар не страшен (секвойя не горит), а вот другие деревья еще как - тем самым выжигая другие деревья и освобождая необходимое жизненное пространство.
тарифы как раз и вводятся, чтобы страны с дешевой рабочей силой не имели этого приемущества; к примеру, на днях тайванский доллар по отношению к американскому собрату подскочил на 6,5%, то есть тайванским буржуям дешевые тайвайские рабочие руки стали на 6,5% дороже и так будет везде
А никто не задумывался, почему все эти предпринимательские изыски работают именно в Китае? В Китаи не развита инженерия: своровать дизайн; скопировать да, но не придумать самому. Плюс еще помогает налогово-дотационная экономика для таких крупных компаний. А теперь представьте такую ситуация, в одной стране с очень-очень мега крупной экономикой и потребительским рынком приходит президент "Т" и поднимает всем пошлины. И приходят, к ПРИМЕРУ русские договариваться о снижение пошлин, а им говорят: "Хотите продвать свои товары на территории страны без пошлин? Если, да тогда завтра курс рубля к доллару - 30 рублей, либо продаете с пошлиной, но с курсом валют какие вы хотите". И все вот эти "крендиля" с OEM, IDM или ODM перестают работать
Рекурсивный вызов можно добиться на том же х86, то есть первый вызов CALL, а последующие JMP, с небольшими танцами с бубном можно использовать теже самые локальные переменные в стеке...
увы, не реализованов 6502 регистры 6502: A - аккумулятор, 8 бит; X, Y - индексные регистры, 8 бит; PC - счетчик команд, 16 бит; S - указатель стека, 8 бит; P - регистр состояния. Вызов процедуры и прерывания сохраняют счетчик команд в стек.
Я правильно понимаю, у каждой функции есть область сохранения, где она хранит все регистры и в том числе регистр в котором был сохранен обратный адрес?!
я прочитал, и не понял, где "заблуждение"... Хорошо, регистр один, а если вызов процедуры происходит внутри другой процедуры, а если таких вызовов еще несколько, получается вызов новой процедуры затирает старый, где мы должны сохранить старый?
Система инструкции ARM - это старая система (1983) и это пример, как её не нужно делать! В настоящих современных архитектурах производиться разделение пользовательского стека и стека для хранения обратных вызовов и состояний.
Экзотическа, в чем приемущества сохранения обратного вызова в регистре?
Откройте любой сишный исходник на git ... openssh, gnome и другие, чтобы понять что делает конкретно одна функция, нужно не менее 3-5 локальных функциях "провалится", чтобы до браться до функционала... так и регистров не хватит
Вопрос про сложность. Сколько GNOME создает структур в памяти для простой кнопки?
Живучий миф
Активно использую инструкции SSE/AVX/AVX2/AVX512 для обработки текста. Дают хорошие плюшки в производительсности...
согласен, но данному способу представления данных уже более 60 лет, он возник, когда не было вообще понимания как передавать данных от операционной системе к программе или от одной программе к другой; и вот это legacy, сегодня выдают за какую-то генеальность
Бывает моменты, что приходиться считать копейки
Если это только ради grep/sed/awk, то это плохой пример разработки ОС
я не имею виду стандарты текстовых форматов - с этим все понятно; разговор про системные данные, которая возвращаются операционной системой посредством виртуальной файловой системы (например, /proc, /sys, /dev и так далее) - программа их получает в текстовом формате, то есть в этом моменте получаем две бесполезные работы: одну выполняет операционная система парсит бинарные данные в текст, а другую принимающая программа, чтобы получить бинарные значения
бинарные форматы проще представлять структурами и работать с ними
система парсит бинарные данные в текстовые, программа читает их, переводит в бинарную форму, если их не много - это полбеды, а если много, то на момент окончания парсинга - они могут быть уже не актуальными или были изменены другим приложением...
Нет, именно Linux Kernel API, а не какой-то POSIX! Например, попробуй найти функцию POSIX pthread_create среди системных вызовов ядра.
Зачем прикладному программисту знать, где операционная система хранит свою информацию? Ради того чтобы показать, что ядро быстро работает? В Linux очень большой объем кода операционной системы перенесен на прикладной уровень (да виде библиотек, но это прикладной уровень)
В реестре Windows програмисту не приходиться самому перебирать "key-value", у реестра свой - API, то есть функции Registry functions. В Linux никогда не будет аналогично реестра, потому что это сметри подобно. Если одна программа карява пропишет свою же информацию в реестре, то это будет смерть всему остальному. Поэтому разработчики Linux принимают единственное правильное решение - нет реестра, нет и никакой отвественности
Как программист Linux - овно с которым приходиться мириться, а что вы хотели от системы которая неизменно несет свою концепцию с 70-х годов (пардон, с 90-х). Кроме Linux Kernel API никакого API больше нет. Тотальная "нелюбовь" к бинарным форматам приводит к тому, что значимая часть любой программы (ну, кроме, 'Hello world!') это парсер текстовой информации в бинарный и наоборот. Ах, ну да, есть же множество бибилотек для работы с системой. С бибилотеками отдельная песня: чаще всего не работают даже заявленные функции; накладываются всякие ограничения и недоделанность функционала. Одним словом отсутствует автоматизация работы с операционной системой и приложениями, сплошной ручной труд...
В США в национальном парке «Секвойя» вообще перестали тушить пожары, когда выяснилось, что источником пожаров стали сами секвойи. В жару деревья начинают интесивно смолить и загорается, для самое дерева пожар не страшен (секвойя не горит), а вот другие деревья еще как - тем самым выжигая другие деревья и освобождая необходимое жизненное пространство.
ODM и IDM - это как раз явный признак отсутствия научных и исследовательских школ в Китае
тарифы как раз и вводятся, чтобы страны с дешевой рабочей силой не имели этого приемущества; к примеру, на днях тайванский доллар по отношению к американскому собрату подскочил на 6,5%, то есть тайванским буржуям дешевые тайвайские рабочие руки стали на 6,5% дороже и так будет везде
А никто не задумывался, почему все эти предпринимательские изыски работают именно в Китае? В Китаи не развита инженерия: своровать дизайн; скопировать да, но не придумать самому. Плюс еще помогает налогово-дотационная экономика для таких крупных компаний. А теперь представьте такую ситуация, в одной стране с очень-очень мега крупной экономикой и потребительским рынком приходит президент "Т" и поднимает всем пошлины. И приходят, к ПРИМЕРУ русские договариваться о снижение пошлин, а им говорят: "Хотите продвать свои товары на территории страны без пошлин? Если, да тогда завтра курс рубля к доллару - 30 рублей, либо продаете с пошлиной, но с курсом валют какие вы хотите". И все вот эти "крендиля" с OEM, IDM или ODM перестают работать
ARM хочет усидеть на двух стулья: энергоэффективность и SIMD. Забавно даже наблюдать за этими потугами :)
Ну это дополнительные накладные расходы
Рекурсивный вызов можно добиться на том же х86, то есть первый вызов CALL, а последующие JMP, с небольшими танцами с бубном можно использовать теже самые локальные переменные в стеке...
увы, не реализованов 6502
регистры 6502: A - аккумулятор, 8 бит; X, Y - индексные регистры, 8 бит; PC - счетчик команд, 16 бит; S - указатель стека, 8 бит; P - регистр состояния. Вызов процедуры и прерывания сохраняют счетчик команд в стек.
Я правильно понимаю, у каждой функции есть область сохранения, где она хранит все регистры и в том числе регистр в котором был сохранен обратный адрес?!
я прочитал, и не понял, где "заблуждение"... Хорошо, регистр один, а если вызов процедуры происходит внутри другой процедуры, а если таких вызовов еще несколько, получается вызов новой процедуры затирает старый, где мы должны сохранить старый?
Система инструкции ARM - это старая система (1983) и это пример, как её не нужно делать! В настоящих современных архитектурах производиться разделение пользовательского стека и стека для хранения обратных вызовов и состояний.
Экзотическа, в чем приемущества сохранения обратного вызова в регистре?
Откройте любой сишный исходник на git ... openssh, gnome и другие, чтобы понять что делает конкретно одна функция, нужно не менее 3-5 локальных функциях "провалится", чтобы до браться до функционала... так и регистров не хватит