Большинство заказчиков Altair не носили фенечек и не жили в коммунах.
Автор пытается категоризировать людей по внешнему виду и в этом его ошибка. В Bell Labs, Томпсон, Риччи и прочие тоже не носили фенечек. Да чего там, обыденная для них форма - пиждаки и галстуки. Тем не менее, ОС Unix которую они создали (и попутно язык программирования "Си") - что это как не бунтарство и взрыв свободы ? И технари из Беркли, которые сделали Unix опенсорсным и распространили по всему миру, тоже фенечек не носили, а имели вполне цивильный по тем временам прикид. Дело не в одежде, не во внешнем виде и не в месте работы, а в мышлении и разделяемых ценностях и идеалах. А они были повсеместно такими, что пора освободить компьютер, вычисления и программирование от оков жадных капиталистов. К сожалению, их идеалы мы благополучно слили в соцсетях.
PS: В молодости я предпочитал ходить в белой наглаженной рубашке, в черном пиджаке и в галстуке. Тем не менее, среди моих друзей было полно хайрастых рокенрольщиков, толкиенистов обвешенных феничками, и прочих лиц "очень странной наружности" (таких кстати сейчас на улицах и не встретишь больше). И на рок концерты я тоже в таком прикиде ходил - такой вот у меня был свой стиль протеста. А занимался я продвижением свободы электронного общения - содержал узел сети Fidonet и BBS, разматывал Интернет по городу, через BBS давал бесплатный доступк к Интернет тем, кто этого себе не мог позволить (dialup доступ в 90-х был по карману далеко не всем), продвигал опенсорс.
NOB - No Build system. Эта система сборки содержит один единственный заголовочный файл nob.h, в нем содежится ряд примитивов из которых разработчик складывает себе систему сборки которая собирает весь проект. Очень рекомендую для небольших проектов.
Цель (файл) CmdInput.o зависит от двух файлов: CmdInput.cpp и CC-opt.txt. Чтобы достичь цели, т.е. получить обьектный файл CmdInput.o, необходимо исполнить команду из переменной $(CC), в которой содержится путь к компилятору, с параметрами в переменной $(CCOPT) и плюс дополнительных параметров формируемых из автоматических переменных $< и $@. Переменная $< содержит первый файл из зависимости, а $@ - файл-цель. Это вобщем-то все, что требуется знать про утилиту Make. А, нет, не всё. Нужно еще знать, что команды сборки начинаются с символа TAB (\t) - см. вторую строку. Но последнее не обязательно для BSD make. :-)
Настоящие make-файлы, особенно в реальных проектах, достигают сотен и тысяч строк.
Это совершенно не так! Хороший Makefile весьма лаконичен и содержит всего пару десяток строк, при этом может собирать проекты из сотни тысяч файлов с вызовом препроцессоров, лексических анализаторов и прочего. То, что Вы имеете в виду под Makefile-ом это скорее всего результа работы надстройки - какого нибудь CMake или AutoGen (./configure), который на выходе и создает такие гигантские Makefile-ы не пригодные для прочтения человеком. Make - отличная система сборки проверенная десятками лет. А эти ваши CMake, Bazel, Ninja и прочее - настоящая дрянь усложняющая жизнь разработчику.
Спасибо за познавательную статью для начинающих. С Вашего позволения немного подушню.
В физическом мире уязвимое место триггера — это его тактируемый вход C. Мгновенный скачок напряжения может открыть триггер, что приведет к нежелательным изменениям данных. Для повышения отказоустойчивости триггеры последовательно соединяют друг с другом.
Такая «шлюзовая система» из триггеров практически гарантирует отказоустойчивость.
Это не совсме так. Точнее, совсем не так. Поясню.
Основная проблема одинарного D-трриггера это подверженноcть "гонкам" и "цифровому дребезгу". В сложной комбинационной схеме (это где присутствуют только одни логические элементы) сигналы могут проходить множество различных путей, каждый из которых отличается суммарной задержкой. Логические вентили срабатывают не мгновенно, у каждого есть ряд характеристик, в том числе propagation delay (время распространения сигнала). Это приводит очень интересному эффекту: изменение одного входного сигнала сложной комбинационной схемы вызывает множественные изменения ("дребезг") выходного, потому как вентили переключаются многократно, по мере того, как к ним поступают сигналы с задержкой. Все это происходит некоторое время, пока вся комбинационная схема не установится в каком-то стабильном состоянии. Чтобы триггер защелкнул правильное состояние сигнала на его входе, а не какое-то случайное промежуточное, была придумана схема типа "push-pull" ("master-slave", "тяни-толкай"). Такой сдвоенный триггер принято называть "Flip-Flop" (в русскоязычной литературе - двухтактный D-триггер).
Работает он так: по переднему фронту блокируется второй триггер (slave) и разблокируется первый (master). В этот момент начиную "клацать" вентили в комбинационной схеме до триггера, т.е. проистекают переходные процессы. Предполагается, что все переходные процессы должны завершиться за 2/3 длительности положительного значения тактового сигнала. Далее, на линии тактового сигнала наступает спад, вход первого триггера блокируется (что тоже происходит не мгновенно) и триггер сохраняет состояние входного сигнала. Спустя некоторое время равное tDelay инвертора, которым связаны тактовые входы двух триггеров, разблокируется второй триггер и его значение меняется на то, что было защелкнуто в первом триггере. Там оно удерживается до следующего спада тактового сигнала.
Но самое интересное состоит в том, что даже FF (двухтактный D-триггер) не решает полностью проблемы гонки, он лишь уменьшает вероятность защелкивания некорректного значения. Часто в схемах можно видеть последовательные цепочки из двух и более таких триггеров - вот такое решение считается достаточно надежным. :-)
Количество триггеров, управляемых общим тактовым сигналом, соответствует разрядности данных, которые может обрабатывать процессор: 32 триггера, например, принимают 32-разрядные данные (то есть 32 бита информации в один момент)
Такую схему принято называть регистром. Существует множество разновидностей регистров: с последовательной или параллельной загрузкой, с синхронным или асинхронным сбросом, с одним портом или многопортовые, и т.д.
Мне стало интересно, можно ли на этом Falstad засимулировать простейший CPU (например, однотактовый RV32I), чтобы показывать студентам какие проистекают процессы в Data Path на уровне единичных вентилей. Быстрый поиск результатов не дал (скорее всего - нельзя). Но зато нашлась статья с описанием симуляции на Falstad игры Atari Pong 1972 г.
Что именно поменять? Есть пример ? В скриптах можно отправить весь .rodata в SPIFI, но этого как раз мне не надо. Мне требуется отправить в SPIFI только строки.
Поясню. В наших проектах используется оба вида памяти - EEPROM и SPIFI. По умлолчанию компилятор запихивает все строки в сегмент .rodata, который размещается в EEPROM (нам важно чтобы .rodata был именно в EEPROM). Как сказать компилятору, чтобы все строки уходили в сегмент .spifi.text или в .spifi.rodata которые размещаются в SPIFI ?
А мне вот доставляет удовольствие поработать именно паяльником, что нибудь поколхозить из микроконтроллеров, а потом запрограммировать. Виртуальные системы как-то не вставляют.
Мы преобрели комплект СБИС на рынке в Запорожье, проблема была скорее в деньгах которые пионеру было сложно добыть (но способы были - сдача бутылок, макулатуры, металлома). Логику, ОЗУ и ПЗУ батя другана принес с завода. С КР580ВМ80А (ИК80А) была заморочка связанная с питанием - его нужно было подавать в определенной последовательности. На сколько помню, если вовремя не подать -5В, то проц сдыхал.
Кстати, как Вы сообщаете компилятору чтобы он перенес строки текста в SPIFI ? Ничего лучше чем attribute ((used, section (".spifi.text"))) перед обьвлением переменной я пока не придумал.
Поэтому некая "каноническая форма" никак не может быть без RTOS. Без RTOS ни стек TСP/IP, ни Bluetooth, ни файловую систему ни что-то другое серьезное невозможно нормально интегрировать.
Вы сейчас действительно про Embedded приложения говорите ? Тогда понятно откуда у холодильников и СВЧ печей потребность в облачных сервисах. ;-)
А вот и пиджаки подтянулись... ;)
Дочитал до конца. Статья хороша, спасибо за перевод.
Уж не знаю, автор ли, или переводчик, но слог сильно похож на Стивена Леви. :)
Автор пытается категоризировать людей по внешнему виду и в этом его ошибка. В Bell Labs, Томпсон, Риччи и прочие тоже не носили фенечек. Да чего там, обыденная для них форма - пиждаки и галстуки. Тем не менее, ОС Unix которую они создали (и попутно язык программирования "Си") - что это как не бунтарство и взрыв свободы ? И технари из Беркли, которые сделали Unix опенсорсным и распространили по всему миру, тоже фенечек не носили, а имели вполне цивильный по тем временам прикид. Дело не в одежде, не во внешнем виде и не в месте работы, а в мышлении и разделяемых ценностях и идеалах. А они были повсеместно такими, что пора освободить компьютер, вычисления и программирование от оков жадных капиталистов. К сожалению, их идеалы мы благополучно слили в соцсетях.
PS: В молодости я предпочитал ходить в белой наглаженной рубашке, в черном пиджаке и в галстуке. Тем не менее, среди моих друзей было полно хайрастых рокенрольщиков, толкиенистов обвешенных феничками, и прочих лиц "очень странной наружности" (таких кстати сейчас на улицах и не встретишь больше). И на рок концерты я тоже в таком прикиде ходил - такой вот у меня был свой стиль протеста. А занимался я продвижением свободы электронного общения - содержал узел сети Fidonet и BBS, разматывал Интернет по городу, через BBS давал бесплатный доступк к Интернет тем, кто этого себе не мог позволить (dialup доступ в 90-х был по карману далеко не всем), продвигал опенсорс.
Мега круто, спасибо! Теперь только ей и буду просматривать видосы. :-)
PS: Под фрю собралась без проблем.
PPS: Отправьте эту утилиту в репозиторий FreeBSD, очень полезная штука получилась.
По какой-то неизвестной причине современные разработчики страшно боятся прочитать мануал на make.
А также на введение новых синтаксичеких конструкций. После чего занятся вычищением языка от всякого шлака. Но коммитет невозможно остановить.
NOB - No Build system. Эта система сборки содержит один единственный заголовочный файл nob.h, в нем содежится ряд примитивов из которых разработчик складывает себе систему сборки которая собирает весь проект. Очень рекомендую для небольших проектов.
Вы хотя бы сократите путь к исходному файлу и все будет выглядет ясно и понятно:
Цель (файл) CmdInput.o зависит от двух файлов: CmdInput.cpp и CC-opt.txt. Чтобы достичь цели, т.е. получить обьектный файл CmdInput.o, необходимо исполнить команду из переменной $(CC), в которой содержится путь к компилятору, с параметрами в переменной $(CCOPT) и плюс дополнительных параметров формируемых из автоматических переменных $< и $@. Переменная $< содержит первый файл из зависимости, а $@ - файл-цель. Это вобщем-то все, что требуется знать про утилиту Make. А, нет, не всё. Нужно еще знать, что команды сборки начинаются с символа TAB (\t) - см. вторую строку. Но последнее не обязательно для BSD make. :-)
Это совершенно не так! Хороший Makefile весьма лаконичен и содержит всего пару десяток строк, при этом может собирать проекты из сотни тысяч файлов с вызовом препроцессоров, лексических анализаторов и прочего. То, что Вы имеете в виду под Makefile-ом это скорее всего результа работы надстройки - какого нибудь CMake или AutoGen (./configure), который на выходе и создает такие гигантские Makefile-ы не пригодные для прочтения человеком. Make - отличная система сборки проверенная десятками лет. А эти ваши CMake, Bazel, Ninja и прочее - настоящая дрянь усложняющая жизнь разработчику.
С двумя проводами надежней - можно закодировать тактовый сигнал, и еще ряд управляющих "символов". :)
Спасибо за познавательную статью для начинающих. С Вашего позволения немного подушню.
Это не совсме так. Точнее, совсем не так. Поясню.
Основная проблема одинарного D-трриггера это подверженноcть "гонкам" и "цифровому дребезгу". В сложной комбинационной схеме (это где присутствуют только одни логические элементы) сигналы могут проходить множество различных путей, каждый из которых отличается суммарной задержкой. Логические вентили срабатывают не мгновенно, у каждого есть ряд характеристик, в том числе propagation delay (время распространения сигнала). Это приводит очень интересному эффекту: изменение одного входного сигнала сложной комбинационной схемы вызывает множественные изменения ("дребезг") выходного, потому как вентили переключаются многократно, по мере того, как к ним поступают сигналы с задержкой. Все это происходит некоторое время, пока вся комбинационная схема не установится в каком-то стабильном состоянии. Чтобы триггер защелкнул правильное состояние сигнала на его входе, а не какое-то случайное промежуточное, была придумана схема типа "push-pull" ("master-slave", "тяни-толкай"). Такой сдвоенный триггер принято называть "Flip-Flop" (в русскоязычной литературе - двухтактный D-триггер).
Работает он так: по переднему фронту блокируется второй триггер (slave) и разблокируется первый (master). В этот момент начиную "клацать" вентили в комбинационной схеме до триггера, т.е. проистекают переходные процессы. Предполагается, что все переходные процессы должны завершиться за 2/3 длительности положительного значения тактового сигнала. Далее, на линии тактового сигнала наступает спад, вход первого триггера блокируется (что тоже происходит не мгновенно) и триггер сохраняет состояние входного сигнала. Спустя некоторое время равное tDelay инвертора, которым связаны тактовые входы двух триггеров, разблокируется второй триггер и его значение меняется на то, что было защелкнуто в первом триггере. Там оно удерживается до следующего спада тактового сигнала.
Но самое интересное состоит в том, что даже FF (двухтактный D-триггер) не решает полностью проблемы гонки, он лишь уменьшает вероятность защелкивания некорректного значения. Часто в схемах можно видеть последовательные цепочки из двух и более таких триггеров - вот такое решение считается достаточно надежным. :-)
Такую схему принято называть регистром. Существует множество разновидностей регистров: с последовательной или параллельной загрузкой, с синхронным или асинхронным сбросом, с одним портом или многопортовые, и т.д.
Мне стало интересно, можно ли на этом Falstad засимулировать простейший CPU (например, однотактовый RV32I), чтобы показывать студентам какие проистекают процессы в Data Path на уровне единичных вентилей. Быстрый поиск результатов не дал (скорее всего - нельзя). Но зато нашлась статья с описанием симуляции на Falstad игры Atari Pong 1972 г.
Что именно поменять? Есть пример ? В скриптах можно отправить весь .rodata в SPIFI, но этого как раз мне не надо. Мне требуется отправить в SPIFI только строки.
Круто, спасибо.
Распечатать и положить на полку. Авось, сгодиться когда нибудь. :)
Поясню. В наших проектах используется оба вида памяти - EEPROM и SPIFI. По умлолчанию компилятор запихивает все строки в сегмент .rodata, который размещается в EEPROM (нам важно чтобы .rodata был именно в EEPROM). Как сказать компилятору, чтобы все строки уходили в сегмент .spifi.text или в .spifi.rodata которые размещаются в SPIFI ?
Все это начинает шокировать когда интернет "по белым спискам" включают.
А мне вот доставляет удовольствие поработать именно паяльником, что нибудь поколхозить из микроконтроллеров, а потом запрограммировать. Виртуальные системы как-то не вставляют.
Мы преобрели комплект СБИС на рынке в Запорожье, проблема была скорее в деньгах которые пионеру было сложно добыть (но способы были - сдача бутылок, макулатуры, металлома). Логику, ОЗУ и ПЗУ батя другана принес с завода. С КР580ВМ80А (ИК80А) была заморочка связанная с питанием - его нужно было подавать в определенной последовательности. На сколько помню, если вовремя не подать -5В, то проц сдыхал.
Ох сейчас Вас запинают за такое... но я Вас поддержу. Makefile и vi - наше всё! :)
Ну это совсем не спортивно. :)
Кстати, как Вы сообщаете компилятору чтобы он перенес строки текста в SPIFI ? Ничего лучше чем
attribute((used, section (".spifi.text")))перед обьвлением переменной я пока не придумал.Вы сейчас действительно про Embedded приложения говорите ? Тогда понятно откуда у холодильников и СВЧ печей потребность в облачных сервисах. ;-)