Стандартизация первого уровня (саморезы). Продолжение

В предыдущей заметке, я показал, что есть функции, которые можно стандартизовать (поместить в 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).

4 комментария


  1. Алексей, спасибо за интересный цикл мини-статей!

    Вот вы пишете, что неплохо бы иметь open binary repository в LLVM-формате, чтобы брать оттуда код под любую платформу и не думать о языках. Это здОрово, это просто замечательная идея. Но в этом случае код получается только такой, который работает только на уровне «процессор-оперативная память» и не покидает это местоположение. А как же быть, когда программе нужно выйти за пределы этой среды, т.е. когда нужно с работой с периферией: ведь программа должна еще уметь читать/писать файловую систему, работать с сетью, работать с монитором (если это GUI-приложение), работать с принтером и сканером, с портами в целом. В каждой ОС для этих задач созданы свои собственные API, свои библиотеки. Даже и при работе только на уровне процессора и процессов (если можно так выразиться) уже приходиться работать с API создания потоков, процессов, возможно с какими-то объектами синхронизации уровня ОС (семафорами, событиями, мьютексами и т.п.). Все эти вещи опять же OS-specific, т.е. в каждой среде выполнения, в каждой ОС — своя собственная реализация. Вот как быть с этой стандартизацией? Ведь она ничуть не менее важна для «обычных» программ. А тут уже LLVM не отделаешься.

    С уважением, Антон Алисов (компания Консультант)

    Ответить

    1. Антон, все верно — следом за первым уровнем стандартизации, нужен следующий уровень. А первый — это простейший уровень — уровень «саморезов».

      Всего я вижу 4 уровня существенно разных уровня стандартизации или уровня «компонент».

      На мой взгляд, принципиальной ошибкой всех попыток сделать «компонентное» программирование, начиная с COM/DCOM было сваливание всего в кучу. Простые решения для сложных задач могут быть построены только путем разделения на уровни. Для каждого уровня свой подход.

      Постараюсь написать достаточно быстро про второй уровень — на котором появляется взаимодействие с ОС.

      Ответить

  2. Спасибо, Алексей, будет очень интересно почитать!
    Вот недавно на Хабре статья была с конспектом лекции Ефима Гринкруга (завкафедрой системного программирования ИСП РАН), описывающая похожие задумки (правда там много воды :) ):
    https://habrahabr.ru/company/yandex/blog/307384/

    Ответить

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *