LINUX.ORG.RU

Си. Почему бы не запретить запись в стек?

 


1

2

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

#include <stdio.h>

register long unsigned rsp asm("rsp");

void print_arg(int arg) {
    ((int*)rsp)[3] = 0xBADC0DE;
    printf("arg = %x\n", arg);
}

int main(int argc, char **argv) {
    print_arg(0xF00D);
    return 0;
}

Этот код отрабатывает и не выводит ошибкок с

-fhardened -fcf-protection=full

На мой взгляд выглядит небезопасно.

Почему бы не вставлять проверки на ассемблере при записи в память, на включаемость в регион стека? Если нужно записать что то в аргумент на стеке (int), то проверку можно не вставлять. При записи по указателю, уже обязательно вставлять. Если адрес стека то ошибка. В memset проверять пересечение двух диапазонов.

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

void read_file(const char *name)
{
        char buff[999];
        FILE *f = fopen(name, "rb");
        read_block(f, buff);
}

void read_block(FILE *f, char *buff)
{
        // тут компилятор должен вывести что len(buff) == 999
        fread(buff, 1, 9999, f);
}

Что бы все идеально работало, нужно будет:

  • Пометить libc функции
  • Если функция работает со стеком как у меня в верхнем примере, но это правильное поведение, пометить и ее
  • Перекомпилировать основные библиотеки, что бы не ломать ABI можно ввести экспорт двух прототипов, с доп.значениями для проверки диапазонов и без, дублирование прототипов понадобится для малого числа функций
★★★

Ответ на: комментарий от anonymous

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

У них там вот такой венегрет из двух языков в коде не встречается

LinkНаселённыйПункт

Ну и есть традиции - что-то ни математики ни физики в своих формулах русские буквы не пишут. И в программировании есть классическое правило именования идентификаторов - его прямо на первом занятии проходят. Может я слишком хорошо учился, но вот такое как в примере выше - мне режет глаз также как иных людей бесят слова типа «ложить» когда в текстах попадаются. Кстати, «населенный пункт» можно написать по-английски как locality,что еще и короче будет. Российские врачи пишут же в рецептах вообще на «мертвой» латыни. А программисты чем хуже?

watchcat382
()
Ответ на: комментарий от watchcat382

Ну и замечу,что шина,по которой проц общается с ОЗУ - работает быстрее чем шина PCIe. Поэтому даже если будет возможен маппинг в адресное пространство то через PCIe это медленнее.

Latency согласен, PCIe вроде примерно в 10 раз медленнее(это на первый байт, не в курсе насчет если на последний). Но пропускная способность вполне сравнима PCIe 5.0 x16 ~63 GB/s, DDR5 32–64 GB/s.

Я так и не могу понять чего ты хочешь добиться. Тебя не устраивает скорости Sata, так ему на замену пришел NVME, будет и его не хватать новый придумают. Хочешь скорость на уровне ОЗУ так купи пару терабайт оперативки и закешируй туда все данные с дисков, я так для игр которые весят 10-20 гигов сперва кеширую в память которой 32 гигов и уже играю без лагов.

V1KT0P ★★
()
Ответ на: комментарий от arkhnchul

ну так там и не в шину затык, именно чтение с флеша - оно еще медленнее.

Согласен,медленно. Но зачем к этому медленному чтению добавлять еще задержку,вносимую sata интерфейсом (контроллерами на обоих его концах) и необходимостью наличия в ядре ОС специального кода который запрошенные данные через это sata достает? В случае nvme достается быстрее,но всё равно требует дополнительных программных действий прежде чем данные станут непосредственно доступны процессору. Это было необходимо когда адресное пространство процессора было маленьким. Но сейчас-то оно очень сильно больше чем объем накопителей в типичном компе. Соответственно будет логичным отобразить весь накопитель прямо в адресное пространство. Чтобы данные добывались простой командой mov. Заодно пропадет надобность в лишнем слое абстракции в ядре - «блочном устройстве». Кстати, вспомнил где еще применяется прямое отображение накопителя в адресное пространство и execute in place для находящегося в нем кода - в картриджах игровых приставок.

watchcat382
()
Ответ на: комментарий от watchcat382

Чтобы данные добывались простой командой mov.

Если ты хочешь читать файлы командой mov то используй mmap: https://en.wikipedia.org/wiki/Memory-mapped_file

Протоколы SATA и NVMe нужны во первых чтоб процессор не тратил ресурсы на лишнюю работу(этим сейчас занимаются микроконтроллеры накопителей), во вторых чтоб можно было подключать разнообразные устройства даже те что буду созданы в будущем(можно на старых ПК подключить по SATA SSD диски, было бы прямое отображение пришлось бы драйверы писать а там где не написали в пролете). Вот бы такой единый протокол был бы для принтеров и сканеров(то что сейчас даже универсальное не такое уж и универсальное как показывает практика).

V1KT0P ★★
()
Ответ на: комментарий от V1KT0P

Хочешь скорость на уровне ОЗУ так купи пару терабайт оперативки и >закешируй туда все данные с дисков,

Вот примерно это и хочу. Только без необходимости выполнения каких-либо ручных действий,да и вообще программного кода. То есть полностью аппаратно, и не тупо всё подряд,а по запросу(по факту первого обращения к странице).

не устраивает скорости Sata, так ему на замену пришел NVME, будет и его >не хватать новый придумают.

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

Я так и не могу понять чего ты хочешь добиться.

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

watchcat382
()
Ответ на: комментарий от V1KT0P

Если ты хочешь читать файлы командой mov то используй mmap

Это не отменяет пропихивания данных через sata (ну или nvme) интерфейс. Просто скрывает этот процесс от программиста.

Протоколы SATA и NVMe нужны во первых чтоб процессор не тратил ресурсы на >лишнюю работу

А он как раз тратит. Достаточно посмотреть сколько кода в драйвере sata в линуксовом ядре выполняется на каждый запрос. Если бы накопитель был отображен в адресное пространство проца - все это было бы не нужно.

можно на старых ПК подключить по SATA SSD диски

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

подключать разнообразные устройства даже те что буду созданы в будущем

А вот зачем в будущем новые устройства подключать через интерфейсы, сделанные для старых устройств - далеко не очевидно. Шину ISA заменили на PCI и IDE на SATA тоже заменили. Кому надо старое - пользуется старым,кому надо новое - пользуется новым.

Вот бы такой единый протокол был бы для принтеров и сканеров

А как его сделать единым если сами устройства сильно отличаются? Если приводить к какому-то общему знаменателю то многие функции будут недоступны так как отличаются у разных устройств. Что возможно - нижний уровень интерфейса - и так уже одинаковым сделали,большинство техники подключается по usb. А уж какие команды через usb посылать - это от устройства зависит.

watchcat382
()
Ответ на: комментарий от watchcat382

Это не отменяет пропихивания данных через sata (ну или nvme) интерфейс. Просто скрывает этот процесс от программиста.

И это хорошо, ведь через sata данные передаются блоками, тогда как считывание с того-же HDD побайтово/побитово. Что проще один раз получить блок 512 байт или 512 раз получать по 1 байту?

А он как раз тратит. Достаточно посмотреть сколько кода в драйвере sata в линуксовом ядре выполняется на каждый запрос. Если бы накопитель был отображен в адресное пространство проца - все это было бы не нужно.

О да, я прям так и вижу код в ядре для чтения с HDD где нужен реалтайм так как блины не будут ждать пока ядро соизволит прочитать данные. Не будь протокола SATA пришлось бы одно ядро на время чтения блока полностью занимать этим чтением.

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

Для видеокарт где действительно постоянно добавляются разные функции сумели сделать OpenGL/Vulkan. А для принтера и сканера который попроще и базовый функционал крайне минимален. Для принтера параметры бумаги, и растровый/векторный файл для печати, для сканера параметры сканирования и растровый файл скана. Это покрывает 99% нужного функционала.

Если интересно то можешь почитать разработчика драйвера для универсальных протоколов печати/скана: https://habr.com/ru/articles/751214/

V1KT0P ★★
()
Ответ на: комментарий от watchcat382

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

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

Если бы накопитель был отображен в адресное пространство проца - все это было бы не нужно.

(очень) утрированное описание того, что происходит сейчас:

  • процессу нужны данные с устройства из файла foo.bar

  • ядро смотрит куда чево каво, видит, что запрошенный кусок лежит в блоках с 0x8AF45BC4 по 0x8AF4F7DD

  • ядро пинает контроллер «дай мне блоки с 0x8AF45000 по 0x8AF50000»

  • контроллер по DMA перекладывает данные из откуда там они у него лежат в RAM, ядро и процессор в это время заняты другими делами, DMA (почти) аппаратный

  • в MMU взлетает флаг, что данные залились из медленной памяти в быструю и что с ними можно чото делать

  • ядро может переключить процесс на работу с запрошенным куском

ты предлагаешь такое, опять же - сильно утрировано и упрощенно:

  • процессу нужно сложить два инта по адресам 0x8AF45BC4 и 0x8AF4F7DD

  • процесс пинает процессор MOV [0x8AF45BC4], EAX

  • мееееедленно и печально 0x8AF45BC4 ползет из флеша в пока еще холодный кэш, процессор ждет, ибо никаких устаревших костылей для информирования процессора о том, что простая атомарная операция будет выполняться еще хз сколько тысяч тактов, не предусмотрено

  • история повторяется с 0x8AF4F7DD

arkhnchul ★★
()
Последнее исправление: arkhnchul (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Важно не то, в какие именно цифры приходится пересчитывать адреса,а то,что этот пересчет приходится делать вообще.

В обычной DRAM памяти все эти пересчеты тоже есть, она же на низком уровне далеко не устройство с произвольным доступом. Так что цена именно пересчета адреса мизерная (а если аппаратно, то вообще наверно нулевая), и на практике вообще не заметна на фоне доступа по PCIE шине вместо прямого контролера памяти.

anonymous
()
Ответ на: комментарий от watchcat382

С обеспечением равномерности износа ячеек вполне справляются маленькие и дешевые контроллеры,стоящие внутри «флэшек»

По сравнению с ssd очень плохо справляются, если ставить без ухищрений систему на такую флешку, даже например на industrial microSD, то они протираются на порядки быстрее чем ssd такого же объема. Да и на ssd важнее контролер даже чем сами планки памяти, с хорошим контролером и одинаковыми планками памяти проживет намного дольше.

anonymous
()
Ответ на: комментарий от watchcat382

Вон,в микроконтроллерах «не сложилось» и ничего, работают. Почему также не может работать десктоп?

В них обычно флешка только для чтения.

anonymous
()
Ответ на: комментарий от bugfixer

Бред. С абсолютно каждым указателем должен идти ptrEnd, это имеется в виду?

И ptrBegin. Чего сразу бред то (или ты про Брэда Питта;-))? Если это будет на железном уровне поддерживаться, то жить станет проще - но код станет медленней;-)

AntonI ★★★★
()
Ответ на: комментарий от AntonI

И ptrBegin. Чего сразу бред то (или ты про Брэда Питта;-))? Если это будет на железном уровне поддерживаться, то жить станет проще - но код станет медленней;-)

Я на самом деле удивлён - почему об «Intel MPX» никто не вспомнил? И вроде как не самые глупые люди вовлечены были. И ведь выпилили же в итоге - на всех уровнях (железо, компиляторы, ядро). Это ведь именно то чего ТС хотел, нет?

bugfixer ★★★★
()
Ответ на: комментарий от bugfixer

Ну я про интел MPX никогда не слышал.

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

В идеале надо сразу автоматически выяснять - это случайность или злой умысел? У каждого фрагмента кода должен быть чётко зафиксирован автор (нужна база программистов всей Земли), причём местоположение всех авторов кода должно тщательно отслеживаться 24/7. И если в результате анализа выясняется что был злой умысел - бомбить аатора нахрен, прямо вот ракету ему в форточку!!!

Должна быть персональная ответственность ящитаю. Ударим крылатыми ракетами по злоумышленникам рушащим наши стеки. Так победим!

AntonI ★★★★
()
Ответ на: комментарий от bugfixer

Это ведь именно то чего ТС хотел, нет?

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

MOPKOBKA ★★★
() автор топика
Ответ на: комментарий от bugfixer

Из того о чём вы мечтали - это самый быстрый вариант.

Как ты пришел к такому выводу? Я ведь ясно написал что обычные инструкции процессора быстрее Intel MPX, а значит довольно легко можно придти к более правильному выводу что это не самый быстрый вариант?

MOPKOBKA ★★★
() автор топика
Ответ на: комментарий от watchcat382

Кстати, «населенный пункт» можно написать по-английски как locality,что еще и короче будет. Российские врачи пишут же в рецептах вообще на «мертвой» латыни. А программисты чем хуже?

Программистам приходится писать на английском произвольные термины из ТЗ, а врачи не пишут на латыни место работы пациента и жалобы. Как на английском назвать поля ОКАТО и «GUID из ФИАС»?

Вот перевёл программист «населенный пункт» как locality, а потом спустя год другой программист пытается понять «locality» — это «район», «населённый пункт», «элемент планировочной сети» или «элемент улично-дорожной сети».

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

Как на английском назвать поля ОКАТО

Аббревиатуры обычно не переводятся. ОКАТО с точки зрения языка ничем не отличается от NATO.

а потом спустя год другой программист пытается понять «locality»

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

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

watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 1)
Ответ на: комментарий от watchcat382

То есть фактически это будет тоже какой-то [мета]язык программирования. Попытки уже были - Prolog например. Но что-то я не встречал чего-нибудь работоспособного,созданного с использованием Пролога.

на сайте Markus Triska есть хороший такой цикл статеек по прологу.

среди них:

из интересного: например,

  • текстовые адвентюры Interactive Fiction на прологе,
  • LogTalk = Prolog + SmallTalk
  • MUD или скорее MOO (например, LambdaMOO) аналог : logicmoo
    ** движок MOO на прологе; обработка соединений (вместо LambdaMOO похожего на Lua – на LogTalk); реализован движок лиспа для KLIF и подключения онтологий из OpenCyc – вот это довольно мощная вещь

в общем, напрашивается сам собой что-то типа проекта FoNC/STEPS = Frank только не на смоллтоке, OMeta, COLA=Common Object Lambda Architecture by Ian Piumatra, ЕМНИП (и соотвествующая реализация лиспа схемы интегрированной с Си) + Nile/Gezira графический движок

– только на полноценном прологе.

а так, да: про компьютеры пятого поколения кроме практического выхлопа проекта TRON (и кодировку TRON до Unicode) почти ничего не слышно.

anonymous
()
Ответ на: комментарий от watchcat382

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

что-нибудь про управление требованиями и их формализацию в FDD,BDD стиле:

  • Given …/When … / Then … And Then … из Gherkin/Cucumber, Java FitNesse и т.п.

  • схема Захмана (свят-свят-свят, громоздкая она зело) :))

anonymous
()
Ответ на: комментарий от anonymous

Иногда на ЛОР анонимус приносит настолько годные обзорчики по программерским вопросам, что становится очень жалко — ну что ж ему не зарегистрироваться-то, а?

hobbit ★★★★★
()
Ответ на: комментарий от watchcat382

1C всё-таки какой-то недоделанный 4GL ценность которого в общем сомнительна.

ценность 1Cv6: язык запросов + однопоточная логика формирования отчётов

ценность 1Cv7.5, v7.7: язык запросов с группировками по иерархии + нечто среднее между VB6.0, Deplhi, Oberon-2

вот кстати. лучше бы оберон с русскими буквами использовали сразу – глядишь, и не понадобилось бы свой велосипед на С++ изобретать.

1С++: более правильный ООП а не этот огрызок 4GL.

правильный 4GL был на мой взгляд, в Clarion, FileMaker и прочем Cache Object Script.

2Cgpl: ООП ещё более правильный чем в 1С++. например, можно было создавать свои классы и объекты и переопределять стандартные типа ТаблицыЗначений.

1Cv8: свой велосипед типа аналога VB.NET, русскоязычный SQL с ещё парой фишек, «Библиотекой стандартных процедур» что есть нетривиальная реализация паттернов в объектном предметно-ориентированном 4GL где даже свои классы и объекты создавать нельзя.

В общем, так себе велосипед на С++.

Опять же, более нормальный полноценный входной 4GL язык – это например, ИнфоПредприятие (где тупо исходники в FireBird базе хранят) или какой-нибудь СБис++, Перфолента.NET и т.п.

С другой стороны, вот возьми они какой-нибудь Глаголъ Странник (русскоязычный Оберон-2). так как тогда свой велосипед с квадратными колёсами продавать?

Опять же, если есть 4GL. То когда-нибудь должен таки появиться и полноценный 5GL.

В смысле first class environments, first class objects, first class modules, first class macroses.

Какой-нибудь метаязык для метакомпилятора «программируемого языка программирования». что-то вроде станочка для создания своих Language-Oriented Framework и всяческих DSL.

типа ANTLR, K framework, TXR lisp и прочего подобного.

anonymous
()
Ответ на: комментарий от anonymous

18.Meta-interpreters

лисппролог:

If you are interested in interpreters, check out A Couple of Meta-interpreters in Prolog: You can write a meta-interpreter for pure Prolog in at most 4 lines of code! Contrast this with the rather complex meta-interpreters for Lisp.

в общем, он начинает с 9 строчек пролога на прологе mi1, 4 (7) строчек в mi3 и постепенно его оптимизирует мемоизацией с бенчмарками.

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

anonymous
()
Ответ на: комментарий от anonymous

Зря вы сразу «вердикты» выносите по любому ЯП.

Взять ту же 1С 8.x.
Её можно интегрировать несложно с любой библиотекой на Си и C++.
Суждение не о том, что это нужно, а о том что функциональность 1С несложно расширить.

Это не защита 1С, а пример, демонстрирующий, что «вердикты» не полезно «рубить с плеча».

Или к примеру вы упомянули ANTLR и судя по всему вы воспринимаете её функциональность как «никак по другому».
Ошибаетесь!

Много раз говорил о том, что нынешние технологии разработки (не об алгоритмах речь) никто не развивает.
Поэтому-то все сидят в «любимом болоте» ЯП и говорят - ОНО НАШЕ И САМОЕ ЛУЧШЕЕ.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 5)
Ответ на: комментарий от Forum0888

у того же Дмитрия Завалишина была в общем-то разумная мысль про «надземелье» и «подземелье».

то есть: доступа к объекту нет физически, если не знать его ссылку (или почти что ролевой мандатный)

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

вот например, микроядро L4::{Pistaschio,Fiasco}. Фактически и реализует абстрактную фабрику выдающую такой доступ – со всей шаблонной магией С++.

подозреваю, что если оригинальный L3 Йохана Лидтке (который ещё на ассемблере) переписать на инлайн ассемблере в Ada и нормальные var’access вместо нетипизированных var’address выдавать – то ещё попроще и понагляднее будет.

ну или изобретать что-то типа тегированных указателей, и аппаратную защиту на регионы разных тайптегов и какую-то линейно-темпоральную логику и region-based analysis – в общем-то контролируемую память.

ну или изобретать какую-то фабрику на смартпоинтерах через CTFE компиляцию типа как в D на какой-то рефлексии и интроспекции времени компиляции.

так-то в качестве примера можно посмотреть на Singuarity OS с микроядром на С# или ещё каком, или раст-микроядро со всеми этими обёртками unsafe.

ну или

  • доработка линкера, который сможет «на лету» добавить код для проверки.

в оберонах так и поступили, например, в активном обероне с акторной моделью.

в итоге, изобретали свой велосипед модулей – начиная от BlackBox CP и Oberon-2, заканчивая A2 и ActiveOberon.

имхо, лучше бы более подробно описали стандартизированный формат модулей и их метаданных.

и на какой-нибудь аде написали системные вещи типа модулей SYSTEM, KERNEL, StdLoader, StdInterpreter – а всё остальное на обероне оставили бы.

anonymous
()
Ответ на: комментарий от Forum0888

или, если так уж нравится язык 1Сv8 читаемостью – но не нравится его ограниченностью – взять скриптовую реализацию на дотнете с похожим входным языком.

X++ в Axapta, кстати, более полноценно объектно-ориентированный. Ну и где это адекватно используется?

Или к примеру вы упомянули ANTLR и судя по всему вы воспринимаете её функциональность как «никак по другому».

вот на примере с МУМПСами есть дальнейшие варианты 4GL если сам М считать 3GL:

  • Cache Object Script – макросы и ООП, проприетарный
  • Profile Scripting Language – из FIS GT.M: ANTLR, Eclipse, макросы и ООП метакомпиляцией
  • EsiObjects – слой ООП сделан на чистом М; на ANTLRv2 парсер M и транслятор из своего ООП-ного 4GL в базовый М
  • MSH – открытая реализация «типизированного М» с GTK и DLL-ками, компонентами, моделью событий

в общем-то если взять например язык типа Lua и например лисп на Lua вроде Fennel.

или сразу простой лисп типа ribbit, и изобретать всякое first-class anything.

интегрированный с базой данных в духе picolisp-а.

то это получится наиболее близко к искомому 5GL

anonymous
()
Ответ на: комментарий от anonymous

имхо, лучше бы более подробно описали стандартизированный формат модулей и их метаданных.

Да, без этого нужно пытаться понять через анализ исходников - «В чём профит и как этот велоспипед работает».

ИМХО основная проблема в том, что многие разработчики «перепрыгивают сразу пять ступенек».
Это весьма плохо.

Например возьмём графику.
Многие разработчики создают свой API для работы с цветом.

Почему всё так?

Потому, что нет добротного системного подхода к созданию API для работы с графикой.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 1)
Ответ на: комментарий от Forum0888

Сначала разработка core, содержащего API для работы с знаниями. Ёмкая, но супер интересная и нужная задача.

в проекте Cyc и далее OpenCyc поступили просто: ввели лисп-подобный в духе IDEF5 язык представления онтологий KLF, и далее реализовали обучение и инференс в какой-то продукционной системе.

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

другое дело, что всё это на прологе где ещё реализована половина лисп-движка для KLF и прочего.

так что содержательная часть например текстовой RPG-подобной игры там относительно небольшая.

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

anonymous
()
Ответ на: комментарий от Forum0888

Да, без этого нужно пытаться понять через анализ исходников - «В чём профит и как этот велоспипед работает».

понимать нужно на основе каких-то наглядных примеров.

вот например, Delphi RAD:

  1. рисуем форму
  2. привязываем события

BlackBox Component Pascal RAD:

  1. пишем модуль
  2. генерируем форму
  3. переключаемся «в режим предприятия» и тестируем недописанные события

Doplhin SmallTalk RAD: MVP: Model-View-Presenter, местный MVC:

  1. пишем value: model,
  2. рисуем view
  3. генерируем Presenter, события на основе метаклассов и рефлексии

PicoLisp:

  1. пишем DSL с Entity-Relation, prefix classes
  2. генерирует персистентные объекты и relational daemon автоматически инфраструктура пиколиспа

то есть: смотреть нужно какие-то showcases как всё работает в целом – а не только исходники.

Потому, что нет добротного системного подхода к созданию API для работы с графикой.

в этом смысле даже tk и его expect (для управления графическими tk приложениями) не выглядит таким уж ужасным.

или какой-нибудь Wayland, прости господи – где нужно просто отдавать картинку.

а вообще, нужно кодогенерировать всё это десктопно-графическое API вроде какого-нибудь IUP,Nuklear,SDL или ещё какого Vulkan из более высокоуровневого представления :))

но у них этот view сильно завязан на controller, presenter.

anonymous
()
Ответ на: комментарий от anonymous

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

Forum0888
()
Ответ на: комментарий от watchcat382

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

вообще да, интересно почему исторически сложилось именно так а не по-другому.

например, в MULTICS Project Mac изначальном были идеи:

  • реализация ядра на высокоуровневом языке PL/I
  • отдельный аппаратный процессор ввода-вывода
  • шелл, командная строка
  • файловая система: иерархические директории
  • ролевой мандатный доступ везде (как бы не A1)
  • виртуальное линейное адресное пространство и подкачка страниц процессов
  • файловые сегменты данных и персистентные сериализуемые объекты типа ISAM баз данных

последнее толком нигде не реализовано полноценно: были ресурсные форки в Apple HFS+ файловой системе и далее NTFS метаданные, но это не то.

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

с готовыми «персистентными объектами».

например, в том же андроиде есть всякие activities. но это тоже не совсем то.

странно, что при повторной реализации ос Multics на C (и получился Unix) эти идеи так и не дошли до нормальной реализации.

впрочем, Unics на C SVR1 на мой взгляд надо сравнивать с TRIPOS и BCPL – и полувековой данности костылями в виде отсутствия типизации указателей (все данные в BCPL бестиповые размером 1 слово).

anonymous
()
Ответ на: комментарий от watchcat382

Почему и упоминал ссылку на готовую реализацию кэш-контроллера на ПЛИС.

то есть, опять изобретаете IO Processing Unit как в Multics или Vax-ах.

другое дело, что например в AMIGA на основе Motorola 680x0 это даже неплохо работало: был отдельный DMA и несколько классов памяти: Fast RAM (SRAM/DRAM с доступом CPU, Blitter, Copper, Denise, Agnus, Paula) и Chip RAM (остальная дополнительная DRAM размером более первого мегабайта)

и например, пересылка спрайта (blitter) или отрисовка во время обратного хода луча (copper) или звуковой и прочие сопроцессоры – работали на DMA с этой быстрой памятью, не задействуя центральный процессор вообще.

есть кстати, современая реализация Amiga на FPGA: Apollo.

там реализовали в FPGA «процессор» MC68080, которого в природе физически никогда не существовало (закончилось на MC68060 производительности уровня Pentium 60 и прочих микроконтроллеров типа Coldfire)

в 68080:

  • в два раза больше 64-разрядных а не 32-разрядных регистров
  • полная совместимость ISA «сверху вниз» с 68060
  • реализованы аналоги MMX инструкций.

с последними, судя по бенчмаркам – производительность 300 Mhz FPGA сопоставима с 3200 Ghz Pentium MMX

ему бы ещё реализацию в ASIC, а не ПЛИС или CPLD.

и массовое производство – для снижения себестоимости.

и многоядерность.

anonymous
()
Ответ на: комментарий от watchcat382

в Motorola 68k, кстати, изначально MMU не было в 68000 и он был отдельно реализован. а вообще он там программируемый и довольно сложный.

наверное, подобную идею было бы рационально на каком-то современном аналоге MC 68080 и этом самом бэтмен аполло реализовать

примеры

сравнение с остальными 68k

вампир бэтман аполло, мантикора, огненнаяПтица и ледянойСелезень : гастроном

anonymous
()
Ответ на: комментарий от watchcat382

Разве что система команд упрощена (всего 13 команд) и увеличено число параллельно работающих их очередей. Там же пишут что и задержка всего примерно вдвое меньше чем у «обычного» ssd.

То есть вот просто так,командой mov с заданного адреса там тоже данные не достать.

для сравнения: в Apollo Core AC68080 FPGA core в разделе code snippets есть примеры на ассемблере обращения через DMA на MC68k:

и прочих: LINES.s CUBE.s vampire.s

всё через DMA, на чистом ассемблере – десятки строчек кода, наглядно и очевидно:

  • включили DMA режим и прочие настройки
  • запустили сопроцессор
  • настроили графический конвейер: текстуры, материалы, вершины и т.п.
  • и простенькое: «I like to mov.l it, move it» ручками на ассемблере :)))
anonymous
()
Ответ на: комментарий от watchcat382

в разделе SAGA chipset тоже есть вкусное:

DFF008 DSKDATR ER * * * * Disk data early read (dummy address)

DSKDATR

DSKDAT     026      W       P     Disk DMA data write
DSKDATR    008      ER      P     Disk DMA data read (early read dummy
                                      address)

                 This register is the disk DMA data buffer. It
                 contains two bytes of data that are either sent
                 (written) to or received (read) from the disk.
                 The write mode is enabled by bit 14 of the LENGTH
                 register. The DMA controller automatically
                 transfers data to or from this register and RAM,
                 and when the DMA data is finished (length=0) it
                 causes a disk block interrupt. See interrupts below.

и прочее управление сопроцессорами через DMA.

anonymous
()
Ответ на: комментарий от watchcat382

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

статья про ld --gc-sections в линкере из binutils и соотвествующие linker scripts.

TL;DR:

  1. нет смартлинкера по умолчанию, поэтому для его имитации делают: а) каждую функцию в отдельную секцию б)сборка мусора между секциями

  2. сборка мусора работает как

а)

Compile source files with -ffunction-sections and -fdata-sections to leverage section based GC.

б)

ld –gc-sections can still discard some sections, but the effect is likely very poor

  1. есть ещё такой ключик компилятора:

-fno-unique-section-names – так что изобретать его заново не надо.

в общем, осталось только переписать рантайм какого-нибудь языка программирования чтобы эти секции полноценно использовать (изобретая какую-нибудь контролируемую память из Aды, ога)

anonymous
()
Ответ на: комментарий от anonymous

Опять же, если есть 4GL. То когда-нибудь должен таки появиться и >полноценный 5GL.

И всё это монстрообразие 1С - чтобы товары на складе считать. Как-то из пушки по воробьям получается. Вот уж действительно - почему не взять любой «настоящий» язык программирования и не писать на нем? Наделать библиотек для предметной области. Но тогда непонятно как это продать. Потому что не получится подсадить кучу контор на свой велосипед с квадратными колесами,разобраться в котором могут только «1С-программисты» просто потому что обычные программисты не хотят с этим связываться.

watchcat382
()
Ответ на: комментарий от Forum0888

Взять ту же 1С 8.x. Её можно интегрировать несложно с любой библиотекой на Си и C++.

Если использовать «любые библиотеки» то зачем тогда вообще 1С ? Только ради весьма странного её языка? А почему любой из обычных ЯП не взять и не интегрировать его с любыми библиотеками?

watchcat382
()