В предыдущей заметке, я показал, что есть функции, которые можно стандартизовать (поместить в open binary repository – OBR). Попробуем определить, по каким критериям мы можем выбирать функции для стандартизации.
Кандидатом на стандартизацию является функция, если она удовлетворяет следующим условиям:
- Функция выполняет однозначно понимаемое, достаточно простое действие (легко стандартизовать)
- Функция достаточно часто используются (есть смысл стандартизовать)
- Действие, которое выполняет функция, не является специфичным для одного или нескольких языков программирования
Тригонометрические функции обладают еще одним важным свойством – отсутствием состояния. Это важно, но не является критерием, принципиально ограничивающим попадание в OBR.
Рассмотрим подробнее тригонометрические функции.
| Критерий | Тригонометрическая функция |
| Функция выполняет однозначно понимаемое, достаточно простое действие | Да |
| Функция достаточно часто используются | Статистики использования у меня нет, возможно, что такой статистики вообще нет. Но смысл в стандартизации есть, так как эти функции должны быть под рукой, если понадобятся. |
| Действие, которое выполняет функция не является специфичным для одного или нескольких языков программирования | Да, но есть вопрос о формате данных: форматы параметров и результата |
Форматы данных
Очевидно, что для стандартизации тригонометрических функций нам надо стандартизовать хотя бы форматы вещественных чисел. Например, желательно иметь тригонометрические функции для форматов: float32, float64, float128.
Плюс к этому должны быть:
- Языковая обертка для языков программирования, которые позволяют подключать функции из репозитория. Это в начале, а в идеале наоборот: компиляторы должны понимать формат описания функций репозитория (что-то типа сим-файла Модулы-2 или Оберона, и спаси нас боже от header files!)
- Варианты оптимальных реализаций для разных процессоров и чисто-программные реализаций для тех случаев, когда аппаратной поддержки нет.
- Авто выбор подходящего варианта, программист не должен быть нагружен обязательным выбором.
Если мы смотрим шире, чем только на тригонометрию, стандартизация должна включать (как минимум) типы данных:
bool
int8, int16, int32, int64, тоже самое для unsigned
float32, float64, float128
Типы, специфичные для процессорных архитектур, например, float80 (x86), стандартизовать (на мой взгляд) нет смысла.
О типе CHAR надо говорить особо. И о других «простых» типах тоже (enum, bitset).
Постоянная ссылка
Алексей, спасибо за интересный цикл мини-статей!
Вот вы пишете, что неплохо бы иметь open binary repository в LLVM-формате, чтобы брать оттуда код под любую платформу и не думать о языках. Это здОрово, это просто замечательная идея. Но в этом случае код получается только такой, который работает только на уровне «процессор-оперативная память» и не покидает это местоположение. А как же быть, когда программе нужно выйти за пределы этой среды, т.е. когда нужно с работой с периферией: ведь программа должна еще уметь читать/писать файловую систему, работать с сетью, работать с монитором (если это GUI-приложение), работать с принтером и сканером, с портами в целом. В каждой ОС для этих задач созданы свои собственные API, свои библиотеки. Даже и при работе только на уровне процессора и процессов (если можно так выразиться) уже приходиться работать с API создания потоков, процессов, возможно с какими-то объектами синхронизации уровня ОС (семафорами, событиями, мьютексами и т.п.). Все эти вещи опять же OS-specific, т.е. в каждой среде выполнения, в каждой ОС — своя собственная реализация. Вот как быть с этой стандартизацией? Ведь она ничуть не менее важна для «обычных» программ. А тут уже LLVM не отделаешься.
С уважением, Антон Алисов (компания Консультант)
Постоянная ссылка
Антон, все верно — следом за первым уровнем стандартизации, нужен следующий уровень. А первый — это простейший уровень — уровень «саморезов».
Всего я вижу 4 уровня существенно разных уровня стандартизации или уровня «компонент».
На мой взгляд, принципиальной ошибкой всех попыток сделать «компонентное» программирование, начиная с COM/DCOM было сваливание всего в кучу. Простые решения для сложных задач могут быть построены только путем разделения на уровни. Для каждого уровня свой подход.
Постараюсь написать достаточно быстро про второй уровень — на котором появляется взаимодействие с ОС.
Постоянная ссылка
Спасибо, Алексей, будет очень интересно почитать!
):
Вот недавно на Хабре статья была с конспектом лекции Ефима Гринкруга (завкафедрой системного программирования ИСП РАН), описывающая похожие задумки (правда там много воды
https://habrahabr.ru/company/yandex/blog/307384/
Постоянная ссылка