С чего начать свой путь?

кстати реально в преподавании реально магия(предшественица науке)

до сих пор (уже почти нет) путаю (как правильно называть)где числитель где знаменатель - при том что с прорешкой всегда был «первый в классе»

ибо одно дело навык и понимание - другое - магические словесные формулы без права на их реально эквивалентную формулировку

помню в 7? классе в целом очень хорошую математичку заклинило когда на теме о чётных/не_чётных/«без_чётных»

она отказалась признать правильность констатации не_чётности как f(x)=-f(-x) нужно было добуквенно f(-x)=-f(x)

реальная хохма в обучение что многие абстракции сообщаются как конкретности(ибо так проще воспринять) а вот сам процесс абстрагирования может и затянутся у реципиента до пенсии :)

дык деления нет - есть умножение на обратные к 1

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

работа с этими регистрами - это написание самой оси, собственно. мало кто с этим работал.

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

с дробями ваще не в самих дробях

с дробями трудность в не одномерной нотации - над чертой и под чертой - и вываливанием кучи псевдо-правил которые по факту следствие умножение обратных

т.е на примере «таблицы пифагора» т.е таблицы умножения - по хорошему есть квадрат 10x10 с координатами множителей и произведением в клетке пересечения координат - и наглядно и обучябельно :)

но блин некоторые горе-типографы печатают как набор утверждений от 1*1=1 до 10*10 ... что несколько окосвенивает понимание по первоначалу :)

так и с делением - делают скачёк через «бесконечно не относящееся к делу точку»

тогда как деление это же реально разрезание на равные части

если всё написать на асме

Не, это утопия. Не представляю как за разумное время на асме написать, например, софт для изготовления прошивок FPGA, софт для проектирования микросхем или даже автоматический разводчик печатных плат с ограничениями на задержки — там везде куча эвристических алгоритмов, ибо точных с разумной сложностью не существует. А эта куча требует постоянных модификаций, настроек, тестирования, переписывания и т.п. Шаблонное метапрограммирование на C++ очень помогает, даже если не используется напрямую, а просто как STL-контейнеры которые сделаны на его основе.

объективно вопрос нотации

си(если очистить от некоторых синтаксических шорткатов - которые в некотором смысле perle-подобны)

т.е. асм в виде некоторого структурного да тот же приснопамятный C--

по хорошему удобно когда dsl чётко разграничены

в смысле серию математичесое обеспечение ЭВМ?!

https://publ.lib.ru/ARCHIVES/M/''Matematicheskoe_obespechenie_EVM''_(seriya)/...

примечательно как отличается целевая аудитория - ну и тиражи

да, это утопия. но не из-за ассемблера, а потому что мозга у людей не хватит. написать можно абсолютно всё. вопрос в том, способны ли разработчики писать не на птичьих скриптиках, а на серьёзных ЯП. и тут опять начнутся обвинения в «небезопасности» и прочем, и прочем. но проблема-то не в ассемблерах, а в головах. кто умеет - те пишут. кто не умеет - не пишут. вот и вся простая дихотомия.

опять же, вопрос о «разумном времени» всегда упирается куда? правильно, в реализацию. при неоптимальной реализации всё будет медленно и печально. и так оно и есть при разводке плат и просчитывании прошивок для PLD. ужасно медленно и печально. и я сильно подозреваю, что алгоритмы там ни при чём.

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

https://fantlab.ru/work677

Аннотация: Председатели комитетов конгресса выслушали на заседании об удивительном открытии — возможности вычислять без счетных машин с помощью графитики, и решили строить звездолет нового типа...

1958 - как раз после спутник-шока

если(и когда - и вероятность ща ну если только ии чё на синтезирует) появится ассемблер - из мнемоник в машкод который снимет с кодировщика «излишний» bookkeeping например тоже раскидывание по регистрам

т.е. в идеале нужно писать на каком бесконечнорегистровом асме - и иметь набор резолюций- как это транслировать в реальный машкод без потерь производительности относительно идеального размещения :)

однако люфт экономически оправдан

поэтому и будет разделённость по степени отвязности от платформы али до даже конкретной железной импелентации со своими «неожиданными» побочками от незарегламентированных коротких битовых последовательностей в строго неожиданных адрессах

кстати, да. тут недавно упоминали Колибри ОС: https://git.kolibrios.org/

люди заморочились и написали ось на ассемблере. ничего не пишут про утопии. просто пишут код.

я у себя использую rwasa: https://2ton.com.au/rwasa/ они тоже ничего не пишут про утопии. просто написали полноценный веб-сервер на fasm. он потрясающе быстр и потребляет просто ничтожное количество ресурсов.

так что некоторые «утопии» при должном старании становятся вполне себе реальными проектами.

что мозга у людей не хватит. написать можно

Ну, тут зависит от определения слова «можно». Для меня текущие коллективные способности человеческой популяции являются естественным физическим ограничением, которое превзойти нельзя. По крайней мере за время много меньшее эволюции обезьян или без киборгизации человечества. Ну не может ни один человек эффективно исполнять, например, роль С-компилятора со скоростью компьютерного (даже без оптимизаций). Компилятор в данном случае я рассматриваю просто как абстрактный алгоритм безотносительно пользы его выхлопа.

запускаем ipython

import dis

смотрим как dis.dis(всякое)

вот в чём польза «ассемблера» в доведение до личинки факта что одно и тоже может быть представленно как в нотации «hll» так и в «байтолюбви»

ну почти - ибо всё таки goto в куда-угодно и прочий полиморф-код проще делать на ближе к железу - за то чем больше фаз интерпретации тем более похоже на естественный дебило-интелект

а я не говорила ничего про «коллективные» способности. количество грамотных и мощных разработчиков совсем невелико.

а вот коллективно макаки пишут говновеб. вот это коллективность в чистом виде. полнейший кал на выходе. сейчас их ещё и генератор бреда (т.н. «ИИ») будет заменять и веб вообще превратится в полную шизофазию. к счастью, ещё остались люди, которые пишут что-то не «коллективно», а осознанно и целенаправленно. пусть медленно, зато качественно.

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

Колибри ОС

Все эти оси по сравнению со сложностью всяких навороченных CAD’ов не идут ни в какое сравнение. Даже ядро Linux за исключением отдельных мест типа навороченных ФС, планировщиков и распределителей памяти представляет с алгоритмической точки зрения довольно унылую конструкцию. А CAD’ы непосредственно участвуют в научно-техническом прогрессе — с помощью них проектируются всё более крутые физические устройства (те же процессоры и другие микросхемы), на которых снова запускаются CAD’ы.

Вот современные оптимизирущие компиляторы типа gcc и llvm наверное могут потягаться с CAD’ами по сложности, но там проблема в том, что можно убрать большинство оптимизаций и иметь практически полезный инструмент. C CAD’ами так не получится — они просто станут бесполезны или почти бесполезны.

а я не говорила ничего про «коллективные» способности. количество грамотных и мощных разработчиков совсем невелико.

Я имел в виду абсолютно всех, в том числе единицы мощных. Даже можно представить себе что все вдруг стали мощными — не поможет. Будет лучше только с одной точки зрения — мощным не придётся взаимодейтвовать с тупыми и их жизнь станет радостнее. Но ничего супервыдающегося они на голом ассемблере без метапрограммирования не сделают (напомню, что любой компилятор — это метапрограммный инструмент который пишет программу (машкод) на основе другой программы (исходник)).

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

печатают как набор утверждений от 11=1 до 1010

Некоторым девочкам так легче заучивать, как стишок

а нет тут никакой средней температуры по больнице. один мощный разработчик - это один разработчик. сколько ни плюсуй идиотов к проекту, производительность не улучшится. скорее, даже наоборот. идиоты будут мешать разработке. поэтому реальная скорость определятся теми, кто способен писать код. и делить её на какое-то среднее количество популяции бессмысленно.

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

тщательно продумывать архитектуру,

Так архитектура зависит во многом от алгоритмов, появился новый алгоритм — и для его реализации архитектура не годится, надо переделывать. Да, при грамотном подходе риски можно минимизировать, но исключить при использовании эвристических алгоритмов нельзя, ибо их бесчисленное количество. А все задачи решить точными оптимальными алгоритмами тоже нельзя — для многих практических задач их просто не существует (те самые NP-полные задачи).

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

и да, про «метапрограммирование». напомню лишь, что это вопрос курицы и яйца. и что люди взяли компиляторы не из воздуха, они не прилетели из космоса, их написали другие люди. причём первые компиляторы писали вообще в бинарных кодах. потому что до них компиляторов не было. и ничего, как-то оно развивалось и работало. просто люди умели думать головой, планировать и аккуратно делать свою работу. сейчас изменилось только отношение людей к работе и их умственные способности явно не повысились. поэтому они то упирают на «метапрограммирование» (которое, кстати, появилось вообще недавно по меркам технологий), то жалуются на какую-то «небезопасность». это всё одного поля ягодки.

а нет тут никакой средней температуры по больнице

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

в обсуждаемой тематике новые алгоритмы маловероятны. там всё известно, заезжено до дыр с точки зрения теории и дело действительно лишь в производительности. такие задачи решаются в лоб перебором и никакая «эвристика» ничего не гарантирует. рассуждения об «эвристике» - это попытки людей выдать желаемое за действительное. но задача имеет сложность и она никуда не испарится, как бы ни хотелось.

причём первые компиляторы писали вообще в бинарных кодах

Да ладно заливать, тебе ли не знать про технологию раскрутки (bootstrapping) компилятора. Те что писали в кодах были крайне примитивными и уже на них делали следующую версию и т.д.

Я же не защищаю современных крикунов, они меня самого раздражают, я просто отмечаю тот факт, что есть определённый класс практически важных задач которые на голом ассемблере не решить за разумное время, даже если все станут гениями.

чел не мощьнее 2метрового куба системы нейрологики на элементах планковской длины

итого земля:42

тут опять начнутся обвинения в «небезопасности»

Сейчас вообще какой-то культ «безопасности». И, самое забавное, что именно под соусом «безопасности» проходят самые опасные решения.

Например, с недавнего времени gmail перестал работать без включённого js. Если не включен js, gmail пишет:

To keep your Google Account secure, try signing in on a browser that has JavaScript turned on.

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

я склоняюсь к мысли, что при грамотном проектировании время на разработку значительно сокращается. вопреки идеологии дендрофекального велосипедостроения, которая сейчас стала почему-то популярна среди управленцев (программисты её ненавидят). время. затраченное на планирование, с лихвой окупается отсутствием необходимости всё переделывать из-за кривой архитектуры. технический долг проще не создавать, чем постоянно его платить.

как оптимизировать ось

Выкинуть её нафиг

в обсуждаемой тематике

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

первые компиляторы писали вообще в бинарных кодах

Или всё-таки в десятичных?

ну, этот принцип касается не только программирования, увы. это вообще общая болезнь «борьбы за безопасность». в целом, вместо слова «безопасность» тут можно подставить много чего. это давно проверенный метод довести что угодно до маразма и полной противоположности.

у меня тут банк недавно отколол финт ушами и вместо логина и пароля из 8 символов, которые были, стал предлагать «безопасный» код из 4 десятичных цифр плюс СМС. жесть, конечно. но как я им объясню, что они убили безопасность юзеров своими же собственными руками. кто-то проехался по ушам начальству - и понеслось.

есть определённый класс практически важных задач которые на голом ассемблере не решить

Что такое «на голом ассемблере»?

думаю, что в бинарных. как ты десятичные засунешь в машину? ещё на перфокартах, вероятно. но это в любом случае была непростая задача.

нет, я как раз про алгоритмы разводки разных плат и прочее такое. в системном программировании алгоритмов вообще почти и нет. оно очень простое по своей сути. там нет никакой математики. там на ассемблере разве что криптография. и то она к осям имеет отношение косвенное.

я-то компиляю тулчейны довольно регулярно

Современный gcc или llvm может требовать для раскрутки достаточно мощный компилятор по одной простой причине — С-компиляторы пишут уже очень долго и всегда найдётся нормальный уже откомпилированный C-компилятор с которым можно стартануть.

Насколько я понимаю, никто не раскручивает gcc прямо с машинных кодов — там даже возможности такой может не быть, поскольку когда он появился уже существовали C-компиляторы. Более того, эта возможность может быть утеряна, если процессорная архитектура для которой это делали умерла, а компилятор вполне может неограниченно долго жить самоподдерживаясь предыдущими экземплярами и кросскомпиляцией. Так что не надо тут рассказывать про всяких титанов мысли которые писали в кодах компилятор ANSI C.

культ «безопасности».

И-безопасности

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

возможность может быть утеряна, если процессорная архитектура для которой это делали умерла

Но мы можем симулировать мёртвую архитектуру на живых платформах.

это всё отговорки. ты понимаешь, что неправ, и пытаешься отъехать.

но никуда первый компилятор не денется, как ты не изголяйся. и писать его надо именно в машинном формате, потому что другого просто нет. софт не появлятся от сырости, сам по себе. и если ты конкретно не используешь машинные коды при сборке тулчейна, это не значит, что история развития компиляторов зиждется на каком-то «уже существующем» божественном компиляторе. нет, это было написано людьми, написано вручную.

писать его надо именно в машинном формате

Что такое «машинный формат»?

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

подразумевается

что компиляция в строковые<line-oriented> мнемоники производится до выхода на машину

т.е. без использования автоматизации

только ручной умственный трут

формат, который принимает машина. я играю в кэпа, а ты играешь в иезуита. но это неинтересно. уже утро и мне пора немного поспать.

это хорошо что есть что-либо вам не понятное

у We Programmers есть ответ и вам он понравится

как ты десятичные засунешь в машину? ещё на перфокартах, вероятно

Дональд Кнут (слыхали о таком ) программировал десятичную ЭВМ. И с десятичных перфокарт в десятичном коде, и, по мелочи, с лампово-тумблерно-кнопочной консоли

нет, я как раз про алгоритмы разводки разных плат и прочее такое

Ну попробуй сделать авторазводчик полным перебором, для нормальных плат разумеется, с тысячами и десятками тысяч соединений и кучей слоёв. Результат будешь ждать до конца жизни Солнечной системы. А чтобы не ждать, надо в перебор вносить эвристики. Можно конечно сказать что монстры типа Cadence и Mentor, а также тех кого они купили, всё уже сделали и пришло время переписывать на асме, только зачем? Чтобы прибить гвоздями всё к конкретной архитектуре и типа ускорить? А если и так пользоваться можно, то зачем вообще тратить усилия — из любви к искусству?

Плюс надо понимать, что если вдруг тебе зачем-то понадобилось сделать свой CAD, то Mentor и Cadence с тобой делиться секретами правильной архитектуры не будут, поэтому правильно спланировать всё сразу не выйдет — придётся набивать шишки самостоятельно.

да давно мы не слышале главу фортовского цеха Чака https://en.wikipedia.org/wiki/Charles_H._Moore#:~:text=VLSI CAD system,-,OKAD... Мура

если всё написать на асме, то будет работать в десятки раз быстрее,

Всё-таки преувеличение. Процентов 5%, может быть.