Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
Страниц: [1] 2 3 4 ... 10
 1 
 : Сегодня в 19:35 
Автор Гром - Последний ответ от RXL
Комбинация "xor eax, ex + push eax..." быстрее чем при использовании других регистров и намного быстрее и компактнее, чем заполнение нулевыми литерами.

А ты уверен?
xor eax, eax может быть закодирован одной из двух операций:
XOR r32, r/m32
XOR r/m32, r32
И никакого преимущества над другими РОН регистрами.
С push таже ситуация:
PUSH r32
PUSH r/m32
Никакого преимущества.
Кстати, PUSH imm32 работает с той же скоростью. Различие только в размере инструкций в предвыборке. В цикле скорость один в один.

 2 
 : Сегодня в 19:08 
Автор geser111 - Последний ответ от geser111

Проэкспериментировал  что лучше - запуск через mpc-be0.bat или mplayerc0.bat (соревнование между новым MPC-BE и старым MPC-HC).
Сразу отмечу, что для чистоты эксперимента в каждом случае обнулял Виндовс через F8 + через свою систему обнуления.
Также удалил перед перезагрузкой madvr, чтобы он случайно не повлиял на результат.
Короче говоря оказалось что старый MPC-HC вместе со старым набором кодеков вначале дает казалось бы не насыщенную картинку, но уже через 20 секунд она донастраивается и становится убедительно насыщенной. А в случае нового MPC-BE картинка хоть и более насыщенная, но зато значительно менее детализированная, да и звук какой-то не глубокий. Понятно что новый MPC-BE использует аппаратные кодеки, но в данной битве для меня он проиграл, потому что мимика людей потерялась полностью. Хотел бы я увидеть результат на более крутом железе, но вывод печальный: не все купишь банальным увеличением насыщенности. Нельзя забывать что отказ от использования madvr повлечет за собой абсолютное не засорение системы. И любимые игры, фильмы онлайн, ютуб и другие прелести, типа фото, будут значительно красивее при отказе от mpc-be0.bat в пользу mplayerc0.bat. Все-таки этот плеер и этот рендер MPC-BE + madvr нужны мне и всем остальным для быстрого просмотра BDRemux и для UHD BD. У каждого своя ниша, где-то нужна Лада, чтобы по полям ездить, а где-то Мерседес, чтобы по автобану Улыбаюсь

 3 
 : Сегодня в 19:04 
Автор Гром - Последний ответ от Aether
... , но лично я бы пожертвовал байтом-двумя и сместил "кучу" с "проклятого" места, сохранив совместимость со стандартом.
Возможно, зря я пример с памятью взял, так как это только запутало ситуацию. Предположим, что функция что-то вычисляет и требует полного использования регистра при возврате. В этой ситуации уплотнить её, использовав одно из её невозможных по вычислению значений в качестве флага, будет нельзя. Значит при ошибке внутри неё нужно будет организовать возврат состояния - тратить на это ячейку памяти дорого по одним причинам, а регистр дорого по другим. Сама идея, в теории, использовать контролируемый флаг процессора для сообщения об ошибке не лишена смысла.

А говорите - любите C.
Любовь зла. Улыбаюсь

Идеологически правильный подход (исключения) почему-то тоже восторга не вызвал.
?

А толку с тех условных переходов, если условия перехода вычисляются предыдущим кодом, который не выполняется? Это же генератор случайных чисел (и неуловимых глюков)
Я не сказал, что у меня уже готовое решение. Пока только идея.

Как я вижу работу МП: есть выделенный поток управления, главная задача которого - это доступ к железу, организации памяти, созданию потоков и их переключению. Сами потоки изолированы от железа, не должны порождать никакие прерывания, исключения, чтобы не нарушить расчётного времени собственного исполнения в диспетчере задач, и сделать систему более "прозрачной". В свою очередь, приход и уход данных с сетевой карты или диска также не должен быть прерыванием. Просто, приняв данные, канал связи должен выставить флаг о приёме, чтобы ОС в свободное от выполнения потоков время сумела спокойно проанализировать эти данные и предпринять необходимое. То есть, с точки зрения системы, прерывания для МП не так важны, его задачи не должны гарантировать время, вспомним, что таймеры в том же Linux гарантируют время не меньшее, чем заказанное. То есть, попросив 1 мс можно получить 10 мс, 1 с, но никак не 1 мс или меньше. А с точки зрения МК, которые обслуживают жёсткий режим по времени, прерывания важны, но их не может быть много, я сторонник, если нужно, вставить несколько МК, чем вставить один МП и заниматься отладкой его программных компонентов по времени.

 4 
 : Сегодня в 18:08 
Автор Гром - Последний ответ от Dale
Ситуация: Вы поручаете предоставить Вам 50 байт памяти, когда всего есть 1 КБ. Менеджер памяти возвращает "0" - это не правильно?

Нет. Это признак того, что объем "кучи" исчерпан, и блок выделен не был.

Прекращаем импровизировать, берем в руки стандарт (например, ISO/IEC 9899:1999), читаем. Сначала описание malloc:

Цитата
7.20.3.3 The malloc function

Synopsis
   #include <stdlib.h>
    void *malloc(size_t size);


Description

The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate.

Returns

The malloc function returns either a null pointer or a pointer to the allocated space.

Итак, всего две интерпретации результата вызова malloc: либо пустой указатель (неудача), либо указатель на запрошенный блок (успешное выделение). Теперь разбираемся с указателем:

Цитата
6.3.2.3 Pointers

...
3. An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.55) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.

---
55) The macro NULL is defined in <stddef.h> (and other headers) as a null pointer constant; see 7.17.

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

Нет, всё верно, выделено 50 байт, адрес начала этого блока пространства "0".

Не скажу за всю Одессу, ограничимся только GCC, мануал к которому лежит в пределах протянутой руки. Там указано, что линкер располагает в начале памяти секцию .data (инициализированные статические переменные), затем секцию .bss (неинициализированные статические переменные), затем идут "куча" и в конце - стек. Так что у "кучи" не так много шансов оказаться по нулевому адресу.

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

С точки зрения математики, ноль - это тоже число.

У стандарта C свое мнение по данному вопросу, с которым мы уже ознакомились выше.

Битовые поля, как я понимаю, метод организации структуры

Да, способ плотно упаковать в слово цепочки из одного или нескольких бит.

Вот это как раз костыль, когда самого языка оказывается мало, и прибавляется библиотека, которая пытается как-то это причесать и обобщить.

А говорите - любите C. Тут без этих костылей шагу не ступить. Неужто забыли про errno? Если нет, то чем этот костыль хуже?

Идеологически правильный подход (исключения) почему-то тоже восторга не вызвал.

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

Не делают так в правильных системах. Интерфейсы пакетного обмена обычно имеют собственную буферную память, которую можно считать в удобное время. Увлекаться вычислениями в программах обслуживания прерываний тоже не принято, это первое правило эмбеддера. Считайте в фоне, сколько угодно, а потом максимально быстро передайте готовый результат по прерыванию, когда получатель готов его принять.

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

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

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

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

А толку с тех условных переходов, если условия перехода вычисляются предыдущим кодом, который не выполняется? Это же генератор случайных чисел (и неуловимых глюков)

 5 
 : Сегодня в 18:05 
Автор Гром - Последний ответ от Sla
Цитата
А вообще всё становится веселее, особенно, когда на Вашем устройстве кто-то другой вдруг вздумает запустить ещё и какой-нибудь датчик,
Нет такого кто-то. Система для некто - закрыта.

Есть аппаратные прерывания, есть программные (те же исключения)

Если у вас есть долгие процессы, требующие непрерывность - отключайте прерывания.

Битовые операции.. Ага-ага.. расскажите про 51 серию там совсем нет битовых операций, и битовых регистров.

Не имеет значения не каком языке написан софт. Компилятор сам разберется.

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

Если есть некие процессы требующие быстрого реагирования, то они разносятся в пространстве.
Не надо отдавать все на обработку МП. Задача управляющего МП сбор и реагирования на внешние сигналы.
И принимать решение важности сигнала.


 6 
 : Сегодня в 16:36 
Автор Гром - Последний ответ от Aether
Менеджер памяти возвращает пустой указатель в случае, когда динамическое выделение запрошенного блока невозможно, т.е. "куча" исчерпана. Эта ситуация невозможна лишь при условии наличия бесконечной памяти. Непонятно только, почему "другие" архитектуры так оплошали.
Ситуация: Вы поручаете предоставить Вам 50 байт памяти, когда всего есть 1 КБ. Менеджер памяти возвращает "0" - это не правильно? Нет, всё верно, выделено 50 байт, адрес начала этого блока пространства "0". Такая ситуация не встречается у Интела, но в PIC есть такое понятие, как непрямая адресация. Через неё образуются зоны памяти, которые отсчитываются со своего нуля. Вообще, в любой системе, где код и данные лежат в разных пространствах, ситуация, что Вы получите начало адресного пространства при выделении вероятна. И это не будет ошибкой. А чтобы обойти эту ситуацию на "С" придётся заранее выделять специальную структуру, в которой будет храниться и адрес и состояние ошибки - это неудобно. С точки зрения математики, ноль - это тоже число.

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

Не вижу проблемы включить стандартный заголовок <fenv.h>, а в нужном месте вызвать fetestexcept().
Вот это как раз костыль, когда самого языка оказывается мало, и прибавляется библиотека, которая пытается как-то это причесать и обобщить.


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

А ведь тот же STM32 производительнее раз в сотню.
Я это отношу уже к МП, просто производители решили убить двух зайцев.

Функция, вызываемая через CALL, будет пропущена. Функция, развернутая inline, будет выполнена. Если у них  есть побочные эффекты (а это нередкое явление), состояние программы будет разное.
Я имел ввиду, что с флагом установленным "e" выполняются только команды условного и безусловного переходов, а также команды работы с флагами, в предыдущем посте я это как бы уточнил вскользь, то есть пропуск CALL часть стратегии. Поэтому, развёрнутая функция просто будет представлена более длинной серией NOP. На состоянии программы это не отразится. Если тело блока не отработает ошибку, сбросив флаг, программа завершится. Тут всё решается внутри потока - никаких исключений, прерываний и иже с ними.

У нас просто разные мнения и подходы. Хотя иногда мы говорим об одном и том же, но разными словами.

 7 
 : Сегодня в 14:11 
Автор Гром - Последний ответ от Dale
Дело не в количестве памяти, а в том принципе, что любая функция, которая возвращает результат, не имеет нормальной возможности сообщить об ошибке.

Ну как же не в количестве, когда:
Цитата
Так вот, в рамках системы Интела, да, ситуация когда менеджер памяти вернёт 0 невозможна, а в других архитектурах возможна.
Менеджер памяти возвращает пустой указатель в случае, когда динамическое выделение запрошенного блока невозможно, т.е. "куча" исчерпана. Эта ситуация невозможна лишь при условии наличия бесконечной памяти. Непонятно только, почему "другие" архитектуры так оплошали.

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

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

Если выделять целую ячейку под бит, зачем тогда битовые поля?

А много программистов ставят условие на проверку бесконечности или ухода в область денормализованных чисел, когда точность результата становится сомнительной? Больно много выпороть придётся, а значит дело не в лени, а в системе.

Не вижу проблемы включить стандартный заголовок <fenv.h>, а в нужном месте вызвать fetestexcept(). Программистам, которым лень сделать такую малость в приложении, где это реально важно, лучше заняться чем-нибудь другим, например, мести улицу (хотя и мести они наверняка будут так же неаккуратно).

И то и то прерывает процесс, само разделение понятий в некотором случае условно, а в некотором может иметь аппаратный подтекст.

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

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

Как видим, общего совсем немного.

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

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

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

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

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

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

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

В итоге, я выделяю задачей МК следить за целевым устройством через прерывание, а общаться, например, с ПК бесконечным циклом основного кода.

Это же всего две задачи. Нужно поставить на МК ОС реального времени и запускать независимые задачи под ее управлением. Можно сделать гораздо больше. Вот в былые времена дали бы Вам, скажем, СМ-1420 следить за двумя лампочками? А ведь тот же STM32 производительнее раз в сотню.

Ничего не изменится.

Как же так?
Цитата
все CALL инструкции при поднятом флаге ошибки пропускаются, а безусловные и условные переходы выполняются.
Функция, вызываемая через CALL, будет пропущена. Функция, развернутая inline, будет выполнена. Если у них  есть побочные эффекты (а это нередкое явление), состояние программы будет разное.

Обычный механизм исключений гораздо прозрачнее и удобнее в использовании.

 8 
 : Сегодня в 11:11 
Автор Гром - Последний ответ от Aether
Разве Intel научился делать бесконечную память? И даже если так, как быть с конечной разрядностью адреса?
Дело не в количестве памяти, а в том принципе, что любая функция, которая возвращает результат, не имеет нормальной возможности сообщить об ошибке. А попытки "уплотнения", которые используются в ряде случаев - это больше костыли. Битовые поля - это хорошо, но помним, что выделять придётся целую ячейку памяти или целый регистр под 1 бит. Регистр в этом случае получается дорогим, а обращение к памяти - это сразу потеря в производительности. И если это ещё и в цикле, то само собой торможение умножается.

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

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

Какую же смуту вносит прерывание от сетевого адаптера, получившего фрейм, или от диска, завершившего операцию обмена данными?
В общем случае иерархия. Строго говоря, ни одно устройство последовательной обработки не может обработать параллельные каналы, и чтобы это обойти придумываются способы выделить важное и оставить на потом остальное. Казалось бы просто, но при таком подходе могут создаться ситуации, когда два устройства по вине третьего будут вечно ждать друг друга, когда маленький поток с частыми вызовами срезает производительность всего другого. Ваша статья есть по энкодерам, вот вопрос: что важнее: следить за каналами изменения следящих оптопар или за изменением состояния внешнего порта? А теперь представьте, что такую систему обяжут следить ещё за тремя объектами, и повесят их на прерывания - то, что рано или поздно он ошибётся в координате - гарантировано. В итоге, я выделяю задачей МК следить за целевым устройством через прерывание, а общаться, например, с ПК бесконечным циклом основного кода. А сам ПК (МП) должен иметь нормальную систему менеджмента, как аппаратную, так и компонент ОС, и не пытаться успеть всё сделать разом, задачи реального времени тут весьма ограничены, ненадёжны. И блокировать работу потоков, ставить их на ожидание до прихода данных с диска - это он должен - его задача. Опять таки решение системное.

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

IMHO довольно запутанно и хрупко. А если при оптимизации компилятор раскрыл код inline функции и убрал CALL?
Ничего не изменится.
Код: (C)
{
...
    {
        p = create_object(); // Заполняем указатель на объект, выделяя память.
        if (p == 0) {... Обрабатываем ошибку ...} // Вот этих обработчиков уйма.
        ...
        // Продолжаем работу с созданным объектом
        ...
    }
...
}
Код: (C)
{
...
    {
        p = create_object(); // Заполняем указатель на объект, выделяя память.
        if (_err) { // Если нам нужен свой обработчик ошибки.
        ... Сбрасываем флаг ошибки ...
        ... Обрабатываем ошибку ...}
        // А если обработчик не нужен, то ничего не пишем, так как в DEBUG компилятор должен добавить:
        if (_err) {
        ... Сброс флага ошибки ...
        dprintf("object1.c line 540 create_object error\n");
        ... Выход ...
        } // А в RELEASE этого не будет, он просто проедет до конца тела этого блока.
        ...
        // Продолжаем работу с созданным объектом
        ...
    }
    // Вот здесь идёт проверка, которую вставляет компилятор,
    // если при выходе из тела блока флаг поднят, то программа завершается.
...
}
Фишка в том, что в большинстве случаев обработчики собственного изготовления не понадобятся, и всё безопасно упростится до изложения собственно алгоритма. inline при раскладке предположим упростится до вычисления чего-то, которое не будет произведено из-за флага, и до системного вызова или вызова функции, которые тоже не будут производится. При этом не произойдёт никаких обращений к памяти данных, поэтому ни скорость не пострадает ни ресурсы.

 9 
 : Сегодня в 09:55 
Автор Гром - Последний ответ от Dale
в рамках системы Интела, да, ситуация когда менеджер памяти вернёт 0 невозможна

Разве Intel научился делать бесконечную память? И даже если так, как быть с конечной разрядностью адреса?

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

Несправедливо ожидать столь многого от языка из начала 1970-х. Именно поэтому и идет эволюция языков.

когда мы пишем "return 0;" этот самый "0" попадает в eax (или регистр этой группы), который традиционно называется аккумулятором.

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

На x86, к счастью, свет клином не сошелся (хотя многократно пытался). В мире embedded правят бал другие архитектуры (ARM, PowerPC etc), в которых ничего подобного нет.

Проблема в стандарте IEEE 754, то есть FPU работает с такими категориями данных, которые трудно встречаются в реальных задачах. И программист их не отрабатывает, ссылаясь попросту на то, что их появление маловероятно.

Так проблема в стандарте или все же в программисте? Во втором случае решение простое - выпороть такого программиста на конюшне.

Исключение суть прерывание

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

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

Какую же смуту вносит прерывание от сетевого адаптера, получившего фрейм, или от диска, завершившего операцию обмена данными?

Собственно, как например я вижу работу флага e. Представим, что у нас malloc не выделил память, тогда по возвращению e будет установлен (RETERR), а на запись в регистр нуля даже не надо тратить время.

Пробовали оценить реальную экономию времени?

Далее, все CALL инструкции при поднятом флаге ошибки пропускаются, а безусловные и условные переходы выполняются. Если мы обрабатываем ситуацию, то пишем переход через блок обработки, а если нет, то сам компилятор добавляет код при выходе из тела программы в месте "}" ставя выход из всей программы сразу. В итоге, значительный объём проверок просто будет не нужен. В версии DEBUG компилятор поставит сообщения об ошибке к каждой функции, а в RELEASE можно будет поймать ошибку по положению указателя на момент выхода из программы. Для управления не критичной ситуации с ошибкой потребуется нечто вроде "BCF E", которая сотрёт флаг ошибки и позволит продолжить выполнение функций.

IMHO довольно запутанно и хрупко. А если при оптимизации компилятор раскрыл код inline функции и убрал CALL?

 10 
 : Сегодня в 08:34 
Автор Гром - Последний ответ от Sla
Цитата
Язык человека понятен заказчику, но непонятен машине.

хм.. Всегда думал, что например пролог как раз для этого и был предназначен.

Ладно-ладно, не совсем точное сравнение.

Зачем парсер - если есть конструктор фраз
Взять с
Проверить там, через ... сек

Т.е. вполне вписывающаяся в структуру теста

Да, конечно, нужно обучать..

зы. Это моя первая работа - разработка диагностического комплекса.
Каждый блок прогонялся через тесты, которые были упорядочены в массиве
по принципу
PinUp -10
PinOut - 100
inputSignal - d1
outputSignal - a=0,4-0,45

ox 28лет...ДВК
И работало!!!!


Страниц: [1] 2 3 4 ... 10
Powered by SMF 1.1.21 | SMF © 2015, Simple Machines