TL; DR:
- Есть ли способ указать соглашение о вызовах / способ, которым функция будет извлекать свой аргумент / возвращаемое значение (значения) другой функции после компиляции?
- Возможно ли сгенерировать ассемблерный / машинный код, который позже можно будет оптимизировать в соответствии с контекстом?
- Если это возможно, насколько сложно было бы полагаться на широко используемые / стандартные инструменты (например, g cc или clang для C / C ++) и поддержка всех скомпилированных языков?
В настоящее время я работаю над своего рода движком кода (с открытым исходным кодом), который я хочу сделать как можно более поливалентным, цель состоит в том, чтобы иметь кучу полностью независимых модов, которые могут быть связаны между собой сложным «трубопроводом» система, которая управляет потоком управления и обменом данными между модами, с одной примечательной особенностью - возможность создавать эти связи во время выполнения. Поливалентность для меня означает, что высокая производительность также должна быть достигнута с использованием движка, хотя, вероятно, с немного большей работой, чем при «нормальном» использовании движка.
По разным причинам я пришел к выводу, что моды вероятно, должен быть в какой-то форме ассемблерного кода (скорее всего, сгенерированный путем компиляции какого-либо исходного кода на неуказанном языке, исходная идея заключалась в загрузке динамических c библиотек с использованием dlopen). В настоящее время я изучаю пределы этой идеи (в мысленных экспериментах), и среди всех моих соображений одна проблема возвращается чаще, чем другие: мне нужны моды, чтобы иметь возможность обрабатывать любые типы соглашений о вызовах, и это в основном по 2 причинам;
- Я не хочу предполагать, что у меня достаточно знаний, чтобы знать лучшее соглашение о вызовах / способ передачи данных между модами на каждой возможной архитектуре, поэтому я хочу, чтобы моды не знали способа получения данных.
- В текущей спецификации моды могут делегировать одну задачу другой в середине своего потока управления и должны иметь возможность извлекать произвольный объем данных, как только они возвращаются в. Это невозможно сделать с текущими соглашениями о вызовах, если только не будет передан динамически выделяемый массив, что создает проблемы с производительностью.
С этим тесно связаны несколько других соображений:
- Я хочу, чтобы моды могли производить произвольную оптимизацию (например, путем создания новых модов путем встраивания одного мода в другой)
- Поскольку все это должно быть возможно во время выполнения, я бы очень хотел, чтобы это было быстро, поэтому генерация кода во время компоновки, вероятно, не рекомендуется.
- Моды могут быть связаны с «библиотекой реализации» до запуска программы (в этом случае быстрая компиляция не требуется), что упрощает задача основной программы, позволяя ей просто вызывать
dlopen, как было задумано изначально, или связывание сгенерировано во время выполнения модом (в этом случае требуется быстрая компиляция).
Это должно также имейте в виду, что все эти функции должны быть совместимы с большинством / всеми текущими компилируемыми языками. Я понимаю, что то, о чем я прошу, может оказаться невозможным, но я хочу иметь четкое представление о том, что возможно, а что невозможно и почему, прежде чем выбирать, какие функции оставить.
Я уже начал думать о способе реализации этого, но он неполный и имеет кучу проблем:
Вместо аргументов, передаваемых через списки аргументов, функция будет сохранять свои аргументы как переменные стека, а инициализировать их, вызвав символ, подобный функции (что-то вроде initialize_input_data_pipe(&variable, "pipe name")), который будет предоставлен реализацией.
Несколько проблем, которые я обнаружил с помощью этого метода:
- Игнорирование стандартного способа передачи аргумента может привести к раздутому исходному коду, ошибкам и т. Д. c.
- По соображениям производительности, когда эта функция связана, она должна быть встроена, но, насколько мне известно, это невозможно с библиотеками c Dynami, а также с использованием библиотек stati c и оптимизации времени компоновки / Генерация кода во время компоновки будет довольно медленной.