Ищу сторонние библиотеки (third-party libraries) для FreeBASIC на Windows и DOS

Где в Интернете можно найти полный список сторонних библиотек (third-party libraries), которые можно использовать в программах на FreeBASIC, со ссылками для их скачивания для Windows (начиная с Windows 98) и DOS? Поиск в Яндексе и Google по запросу "Download Third-Party Libraries for FreeBASIC" (без кавычек) не дает никаких результатов.

0

Сообщение от CoderHuligan с своей ide, но не привязано к одной ОС

PB этому соответствует.

Сообщение от CoderHuligan Лучше через p-код, посредством виртуальной машины.

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

Сообщение от CoderHuligan Но виртуальная машина должна быть достаточно компактной и быстрой, что бы быть зашитой в exe.

Насколько компактной? Чем меньше она тем меньше у нее возможностей.
Вообще, у вас какие-то взаимоисключающие требования.
Можете посмотреть на AitoIt. Но там не виртуалка, а чистая интерпретация. Исполняемый файл около 1 МБ.

Сообщение от CoderHuligan При этом мы избежим проблем совместимости версий.

Каким образом? И причем здесь виртуалка?

Сообщение от CoderHuligan Можно будет создавать модули чисто на промежуточном языке, чтобы менять условия компиляции на более высокоуровневом ЯП

Проект в исходниках. Компилируйте его без всякого p-кода.

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

Зачем все это в бейсике?
Это больше нужно вирусописателям чтобы скрыть действия кода.

1

Сообщение от Quiet Snow BYVAL hwnd AS LONG

лучше LONGPTR )

Добавлено через 45 минут

Сообщение от locm Проект в исходниках. Компилируйте его без всякого p-кода.

p-код, вот что на VB дает возможность выполнять код и редактировать одновременно, т.е. компиляция частично может выполняется как бы на лету. Но это я так понимаю, может быть в чем-то ошибаюсь. В vba код компилируется в пи-код, но если взять любые скриптовые языки, то они тоже наверное компилируются в свою версию пи-кода..

0

Сообщение от locm PB этому соответствует.

Забудьте. PB мертв.

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

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

Сообщение от locm Насколько компактной? Чем меньше она тем меньше у нее возможностей.

Настолько насколько она влезла бы в кэш процессора целиком. Добиться этого вполне возможно.

Сообщение от locm Каким образом? И причем здесь виртуалка?

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

Сообщение от locm Проект в исходниках. Компилируйте его без всякого p-кода.

В этом случае сам компилятор остается непрозрачным. Тут остается уповать на самих разработчиков. И если они забили болт на свое творение, то пиши пропало.

Сообщение от locm Зачем все это в бейсике?

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

0

Сообщение от CoderHuligan PB мертв.

Почему так решили?

Сообщение от CoderHuligan Мы сразу же получаем кроссплатформу.

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

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

То есть небольшой исполняемый файл тащит за собой прекомилированные файлы на несколько десятков метров? Чем это лучше?

Сообщение от CoderHuligan В exe зашит только сам механизм исполнения. Компилятор также прекомпилирован и может быть перекомпилирован одной командой.

Вы это, собирались написать компиль и что-то результата нет. Хоть начинали? Рассуждать можно сколько угодно - сделайте и посмотрим что получится.

0

Сообщение от CoderHuligan Ну и пишут наверно эти расширения, благодаря тому, что есть указатели и динамическое выделение памяти. Но зачем тратить на это свое время в basic?

Указатели нужны и асм нужен, кастом и прикладуху никто не отменял.
Печально когда нельзя написать просто что-то наподобие Use png format и потом LoadImage.
И потом rersize и rotate. Разрабы там 25 лет сидят и ни пса не сделали, удивляюсь этим остолопам.

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

А что делать тем, кто эти решения найти не может?

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

Подключить я и на FB могу. Ты понимаешь что "использовать" и "подключать" это разные вещи.
И все эти dll мотающиеся в папке с проектом, я бы их разрабам библиотек в одно место бы засунул.

Сообщение от CoderHuligan Вывод прост: до сих пор не создана достойная альтернатива VB

Ты буковкой ошибся, альтернатива PB. Ибо чтобы к нему приблизиться только и делал что
подключал, подключал и ещё раз подключал. Да и на самом PB тоже люди подключают, но у же
по другим причинам. Но везде свои нюансы в т.ч. и на PB.

Сообщение от CoderHuligan Я не думаю, что путь чистой компиляции в один исполняемый файл это наиболее правильный путь, конкретно для basic.

Ты ошибаешься. Это самый правильный путь и выгодный путь. Но не тогда, когда у руля стоят дебилы.
Потому что если кому-то взбредёт изменить т.н. "промежуточный код" то ты поимеешь примерно
столько же головняка, а то и больше. Потому что кол-во промежуточных звеньев увеличится и их
тоже кому-то придётся обслуживать. А в С(Б)ПО у нас "самообслуживание".

Добавлено через 4 минуты

Сообщение от locm Она может быть на уровне исходника, который компилируем под требуемую платформу.

Абсолютно верно. Более того кроссплатформу ещё можно заложить на идеологическом уровне
если строить ПО на самых базовых элементах, которые есть везде.

Добавлено через 13 минут

Сообщение от CoderHuligan В этом случае сам компилятор остается непрозрачным. Тут остается уповать на самих разработчиков. И если они забили болт на свое творение, то пиши пропало.

Ты просто затираешь нам про лишний слой(интерпретацию) или как модно говорить jit рекомпиляцию.
Так наверное удобнее жить в современном мире, где кол-во говно платформ увеличивается.
А ты не думал что тебе это навязали, чтобы сливать ресурсы в унитаз? Ну знаешь много ресурсов стало,
надо сливать! И тем более если всё то же самое по вопросу "если вдруг разрабы лохи" то смысл?

И ещё раз смысл мне горбатиться на кроссплатформу если я этого не хочу? И когда говорят мол
вот другие платформы? Какие другие? Linux с двумя калеками и Android - который вообще в корне другой
и который мне лично противен сам по себе.
Я уже говорил что если разработчик один, то у него не хватит сил тестить на все платформы, он просто
окакается на месте.
И все эти стада ослов, и юнит тестировщики и QA они нужны когда всё идёт по срокам по скрамам(по "сраму").
И даже в этом случае они зачастую обсираются. А когда работу делают инженеры в нефиксированный
срок и строго по документации, этих трат не надо. Это здравый смысл, которым мир уже давно обделён в погоне
за прибылью.

Добавлено через 3 часа 45 минут

Сообщение от testuser2 лучше LONGPTR )

Я понимаю, что мы дошли до апогея извращений, но да, можно дальше и таки и ПТР туда ещё допихать...
Правда LONG FB-шный не получится, только QB-шный, я вообще не знаю как это говно работает,
это похоже на чёрную дыру в пространстве, через которую утекает функционал одного диалекта к другому)))
При этом учёные не знают по каким законам природы это говно работает)))

И я ещё промолчу про то, что это всё я компилирую 64 битным, а LONG у QB - 32...
Тут мои полномочия просто всё... Где надо - компиль придуривается, а где не надо - "приумнивается" ссучара...

0

Сообщение от Quiet Snow Указатели нужны и асм нужен, кастом и прикладуху никто не отменял.

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

Сообщение от Quiet Snow И все эти dll мотающиеся в папке с проектом, я бы их разрабам библиотек в одно место бы засунул.

Согласен. Но dill могут быть системные, например виндовые api, которые как раз через системные dll работают. И тут уж никуда не денешься, таковы правила игры. Просто они в системной папке лежат и не мозолят глаза .

Сообщение от Quiet Snow Потому что если кому-то взбредёт изменить т.н. "промежуточный код" то ты поимеешь примерно столько же головняка, а то и больше.

Если в обычной виртуальной машине байт-код выполняется непосредственно, то в моем представлении байт-код должен пройти этап компиляции в шитый код, а уж потом идти на выполнение. Причем компилироваться на этапе загрузки модуля с диска. Это должно быть очень быстро. Ну и выполняться быстрее виртуальной машины. Вполне вероятно, что быстрее обычного исполняемого кода если загнать систему в кэш проца. Обычную программу в кэш не засунешь. Туда можно положить только компактную микро-систему. Но это надо еще раскуривать. То есть на низком уровне работает некая обобщенная форт-машина. Байт-код (p-код) очень удобен для переноса и хранения на диске, то есть это прекомпилированный исходный код. И он уже оптимизирован компилятором. Причем можно создавать отдельные модули непосредственно в промежуточном коде.
Возможно то, о чем я говорю сильно похоже на jit компиляцию, но скорее всего несколько отличается от неё.

Сообщение от Quiet Snow Ты просто затираешь нам про лишний слой(интерпретацию) или как модно говорить jit рекомпиляцию. Так наверное удобнее жить в современном мире, где кол-во говно платформ увеличивается. А ты не думал что тебе это навязали, чтобы сливать ресурсы в унитаз?

Какие ресурсы? Наоборот: мы увеличиваем скорость выполнения жертвуя некоторым временем загрузки. Это если проводить jit на этапе загрузки. Причем загружать можно не все модули, а только те, что требуются в данный момент, а это экономит ОЗУ. Нет, тут я вижу только плюсы.

Сообщение от locm Почему так решили?

Потому что код закрыт, а автору светлая память..

Сообщение от locm Она может быть на уровне исходника, который компилируем под требуемую платформу.

Ну и получится вот то, что получилось с fb. Обновляем компилятор, отваливается старый код. А тут достаточно обновить микро-систему, а весь код остается рабочим. Его даже перекомпилировать не требуется. Вы его пишете раз и навсегда.
А исходный обычный код требуется менять на уровне исходника и перекомпилировать все заново например при переносе на другую версию ОС.

Сообщение от locm То есть небольшой исполняемый файл тащит за собой прекомилированные файлы на несколько десятков метров? Чем это лучше?

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

Сообщение от locm Хоть начинали?

Начинал, но бросал, так как было не полностью ясно что делать. Посмотрим.

0

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

Я писал про Pure, а не Power.

Сообщение от CoderHuligan Ну и получится вот то, что получилось с fb. Обновляем компилятор, отваливается старый код.

Не факт. Смотря как и что обновлять.
Точно также можно сказать про ваш метод - обновляем компиль / вируталку и код отваливается.
Вы слишком много пишите про "идеальный" компилятор, но результата нет. Напишите его и тогда поговорим. Иначе приходится работать с тем что есть.

Сообщение от CoderHuligan А тут достаточно обновить микро-систему, а весь код остается рабочим.

А если обновленная микро-система окажется не совсем совместимой с прежним кодом? Такое бывает и часто.

Сообщение от CoderHuligan Так как тут у нас все под руками и можно все исправить на месте.

Что у вас есть под руками на данный момент? Ничего! Вы даже не начали писать этот "идеальный" компилятор.

0

Сообщение от CoderHuligan Я имел ввиду трату времени написание библиотек, которые по идее должны поставляться в базовом комплекте. То есть должна быть своя базовая надежная библиотека чтобы постоянно велосипеды не изобретать. Ну а указатели и асм нужны конечно, для каких то специфических случаев. Но хорошо бы, чтобы они обитали в промежуточном слое, а не наверху. То есть, как вы и писали, про некий форк для создателей статических либ. Это и есть промежуточный язык, то есть некий обобщенный ассемблер, который работает на низком уровне. А то получается, что высокоурвневый код и низкоуровневый, находятся на одном уровне, как это сейчас происходит, это не красиво.

Да не нужно никакого промежуточного слоя, как и "форка". Я это сказал в ключе "если уж им надо было",
но они загадили основной диалект, форк уже не спасёт. И в принципе если подумать ты прав касательно
указателей, просто даже если подумать что разрабы сделают более насыщенный по структурам ЯП,
листы, списки, деревья там добавят, говнокода в комьюнити станет поменьше, но по сути всё равно нельзя быть
полностью уверенным в том что покроются все потребности, поэтому выпиливать указатели это отчаянный
путь, алгоритмистам плоховато будет. Можно просто в справке написать "постарайтесь поменьше
использовать указатели и побольше использовать имеющиеся структуры".

Сообщение от CoderHuligan Какие ресурсы? Наоборот: мы увеличиваем скорость выполнения жертвуя некоторым временем загрузки. Это если проводить jit на этапе загрузки. Причем загружать можно не все модули, а только те, что требуются в данный момент, а это экономит ОЗУ. Нет, тут я вижу только плюсы.

Объясняю, если ты просто заливаешь готовый код в ЦП есть 2 вещи которые позволяют ему работать быстрее
1) Он расходует меньше кеша. (потому что jit - это тоже прога и ей тоже нужен кеш)
2) Меньше расходованного кеша позволяют закешировать что-то ещё.

Сообщение от CoderHuligan Вполне вероятно, что быстрее обычного исполняемого кода если загнать систему в кэш проца.

Да что с вами всеми не так? Ещё один утверждающий, что нативный код медленнее байт кода.
Вот наглядное доказательство, почему людей нужно учить ассемблеру. Ассемблерщик никогда
такой ереси не вспорет.

Сообщение от CoderHuligan Просто они в системной папке лежат и не мозолят глаза .

Я не про системные, системные не вижу и они не мешают.

Добавлено через 14 минут

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

То, про что и говорил. Всё равно "target"-компиляция.
Хулиган, я понимаю что слава net и java тебе затмили глаза, но ты как-то обмозгуй эти вещи
и всё что сейчас в IT происходит. А происходит много, но не сильно интересного, банального.
Людям уже 20 лет компоссируют мозги микроскопическими хардварными шажками, софт
при этом "догоняет"(в обратном направлении) быстрее. И тут ты вылезаешь с идеей,
которую до тебя уже куча фирм сделала давным давно, как думаешь их опыт хуже твоего?

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

0

CoderHuligan, как твои дела, куда пропал?

Помню ты rust упоминал, вот тут чувак тоже решил это сделать:

https://ifnotnil.com/t/about-p... video/4127

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

Вот они современные программеры. И снова, превращая бейсик в си, радуются подобному дерьму,
"who needs c?", ну да снежинки рисовать на raylib самое то. Надо ему сказать было, а без raylib слабо?
И о боже, чтобы использовать число пи он подключает соотв. math хедер))) даже так, вот прямо так.
Но зато линкует как бог, одно говно к другому прилинковал и оно даже заработало. И тут вопрос,
а если бы не заработало? Как с пуриком было бы? Мол "it's useless!"... ахаха

1

Сообщение от Quiet Snow Развлекательный контент, можно смотреть вместо выпусков Задорнова.

Распаковав архив он не увидел файлы README и INSTALL?
Если не ошибаюсь это же видео обсуждалось на официальном форуме https://www.purebasic.fr/engli... hp?t=85353

Фред тем временем выпустил версию для Windows ARM64.

0

Сообщение от locm Фред тем временем выпустил версию для Windows ARM64.

Молодец Фред. Ты тестировал кстати? У меня просто даже такого устройства нет на ARM с виндой.
Но ноутов бюджетных понаклепали много одно время, прям ажиотаж был по ценам.

Сам просто не вижу особого смысла, всю жизнь пользовался x86 и она значительно обширнее по софту,
а тут изо всех щелей прёт этот ARM. Ноуты возможно когда-то и возымеют массовый успех,
но это скорее всего будет не винда, потому что винда ассоциируется с x86 и горой софта, написанного
за 30 лет. Крупные компании конечно своё портируют, а вот мелкие прогеры - ясен пень нет.
Но общество подготавливают к отказу от старых приятных вещей, я вот только не уверен, что все
с этим согласны.

Сообщение от locm Распаковав архив он не увидел файлы README и INSTALL?

Думаю он действовал как любой классический линуксоид. Хотя и сам Фред пишет

Indeed it should work outside the box, and it does on Windows/MacOS but not on Linux. Will be sorted soon.

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

Добавлено через 9 минут
Хотя вроде он написал что уже все поправили:

I updated the linux package to work as expected out of the box.

0

Сообщение от Quiet Snow как твои дела, куда пропал?

Нормально. Погрузился в чтение литературы. Пот Tcl\tk книгу Уолша штудирую. Просто нравится эта технология, но не без недостатков. По ассемблеру GAS курс прочитал. Теперь еще читаю мануал по MASM. И книгу Карпова по теории компиляторов перечитываю. Хорошо, что Ютуб отключили, теперь времени больше стало.)) Так что времени почти нет.

Сообщение от Quiet Snow Помню ты rust упоминал, вот тут чувак тоже решил это сделать:

Через proxi зашел немного посмотрел. Но у меня прокси только на час в сутки.. А платить не хочется.

Сообщение от Quiet Snow И снова, превращая бейсик в си, радуются подобному дерьму, "who needs c?", ну да снежинки рисовать на raylib самое то.

Это про free basic? Мне вообще ни один basic из современных реализаций не вкатывает. Ну, так чтобы просто перло от того, что ты пишешь на нем. Нет такого. И от С уже не прет.. На плюсы даже смотреть без отвращения невозможно. Питон, который в тренде на первом месте, есть убожество.
Я вот сейчас загорелся сделать С библиотеку реализации динамических строк, списков, кортежей, хэш таблиц так как я это понимаю. Вот смотрю на все эти реализации, которые полагаются на сишные realloc и четко понимаю, что это какие-то детские штанишки. Ну вот смотрите: зачем при выделении дополнительной памяти постоянно копировать данные из старого блока в новый? Ну вот зачем? Допустим происходит конкатенация двух строк, и надо выделить дополнительную память. Во free basic это делается тупо выделением ровно столько памяти, сколько нужно и копированием первой строки в новый блок, копированием второй туда же и освобождением старого блока. Даже если мы присоединяем всего один символ, то дергается realloc. Все знают что сишные malloc тормозные. Но обычно для добавления в список одного элемента дергается malloc по каждому элементу и при удалении дергается free также по каждому элементу. Хотя по идее надо бы добавлять удаленные в свой список, а при добавлении сперва проверять пуст ли он и если нет, то добавлять туда, в этом случае мы избегаем лишнего вызова malloc. И выделать память надо блоками кратными степени двойки, тогда избегаем дефрагментации памяти. Также надо сделать отдельные модуль менеджер памяти, который отслеживал бы висячие указатели и пр. Если под капотом вот это, то уже жить можно и легче. Вот почему все так медленно.
Да и не думаю, я что интерпретация это наше всё. Скорее это большой тупик..
И я вовсе не думаю, что в одиночку могу потянуть то, что например Sun разрабатывала годами с сотнями сотрудников. Вот почему я изучаю уже готовые решения.
Реализовать язык к примеру в одиночку сейчас довольно просто, хотя и потребуется довольно много времени. А вот создать окружение, на это просто времени не хватит, потому что тут уже нужна команда. Если же ограничить возможности языка чисто домашними нуждами, то можно потянуть. А этого в большинстве случаев хватает. А мы вынуждены стрелять из пушки по воробьям пользуясь монстрообразными системами. Одна visual studio весит за гигабайт..

0

Сообщение от Quiet Snow Ты тестировал кстати?

Тестировал. Есть баги, но первая версия и пока что бета. Фред исправит.

Сообщение от Quiet Snow У меня просто даже такого устройства нет на ARM с виндой.

На малину, апельсину, банану и др. микрокомпы можно установить Win10 arm64. Винда на MicroSD карте работает не быстро, но для теста достаточно.

Сообщение от Quiet Snow потому что винда ассоциируется с x86 и горой софта, написанного за 30 лет.

В ARM винде нормально запускаются приложения для x86 и режиме эмуляции.

Intel и AMD сосредоточились на компах и проворонили все остальные ниши. В роутерах, телевизорах, телефонах / планшетах используются ARM процы, а не x86/x64. Даже микроконтроллеры с какими хочешь ARM ядрами, а с x86/x64 я не видел.
"Надкусанное яблоко" тоже перешло на ARM и достаточно успешно https://ru.wikipedia.org/wiki/Apple_M3
https://ru.wikipedia.org/wiki/... le_Silicon
Пишут что x86/x64 сильно проигрывает им по производительности.

Сообщение от CoderHuligan И выделать память надо блоками кратными степени двойки

Перерасход памяти.
Если она строка, то ладно, а если миллион?

0

Сообщение от locm Если она строка, то ладно, а если миллион?

А у меня нет излишнего копирования. Копирование только когда надо заполнить пустое пространство выделенное под строку. Доупустим строка имеет размер 20 байт. Под размещение выделено 32 байта. 12 свободных байт могут заполниться если строка должна вырасти, плюс если места не хватает выделяется дополнительный блок равный размеру присоединяемой строки плюс выравнивание в степень двойки. Блок добавляется в список, а указатель на него из первого блока. То есть строка может представлять из себя фрагментированную последовательность, но обработчики учитывают этот момент. Это похоже на файловую систему, когда файл может быть фрагментирован, но только в оперативной памяти. При удалении какого либо блока, он помещается в список удаленных. Причем этим списком могут пользоваться и иные структуры данных, так как размер блоков одинаков для всех.

0

Сообщение от locm Пишут что x86/x64 сильно проигрывает им по производительности.

Там не в процах дело. Они софт заточили как всегда и из видео дров выжали максимум.
Они очень много денег вливают в свою экосистему, что, считаю, правильно. Иначе им не окупить свои ценники.
Раньше тоже у них все "летало" по словам владельцев даже на кор дуо, которые они ставили.
ARM-ы они по сути мобильные, десктопы намного сильнее. У ARM нет настолько продвинутых SIMD
инструкций, есть там какие-то, но не сравнить. Основная их фишка в энергосбережении,
поэтому могут распихать больше ядер и распараллелить софт.

Сообщение от CoderHuligan Допустим происходит конкатенация двух строк, и надо выделить дополнительную память. Во free basic это делается тупо выделением ровно столько памяти, сколько нужно и копированием первой строки в новый блок, копированием второй туда же и освобождением старого блока. Даже если мы присоединяем всего один символ, то дергается realloc.

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

Гораздо эффективнее предусматривать целевые точечные оптимизации уже в самом софте. Т.е. это прежде
всего работа над структурами и архитектурой софта с точки зрения их максимальной эффективности.
А не глобально с точки зрения компиляции.

А если речь о своём компиляторе. То опять же зарешает общая оптимизация, а не частная каких-то отдельных
аспектов типа строк.

Сообщение от CoderHuligan По ассемблеру GAS курс прочитал. Теперь еще читаю мануал по MASM.

Ну вот услышал меня, ASM подтягиваешь, давай давай, дядька, не расслабляйся.
Я GAS вот не хочу, ну его в попу, подыскал другой хочу uasm поизучать. Так бы и FASM сошёл, он прикольный,
но там лицензия кривая, не факт же что буду всегда СПО пилить, надо на будущее смотреть.
А MASM дальше 5 версии под DOS превратился в лютое фуфло. А современные ещё надо из
майкровских студий руками выцарапывать, не могли отдельный пакет сделать, дебилы)))

Добавлено через 9 минут

Сообщение от locm В роутерах, телевизорах, телефонах / планшетах используются ARM процы, а не x86/x64. Даже микроконтроллеры с какими хочешь ARM ядрами, а с x86/x64 я не видел.

Это всё понятно. Если говорить по хорошему, в мире где человек понимает что такое быстродействие,
в таком мире, на мой взгляд им не занять x86 рынок. С другой стороны человек уже не очень то и понимает
что и насколько лучше работает. Людям понравился андроид, а это страшное дерьмо. Так что может
быть всё что угодно и ARM-ы на десктопах через 5-10 лет.
У Intel-а же дела очень плохи, там руководство - мудаки. С другой стороны не понимаю почему они
не могут заключть fabless контракты(параллельно строя свои заводы) и поконкурировать нормально с AMD
на одинаковых условиях. Они уже стремительно идут на дно и судя по анонсам просрали последние свои шансы.

Добавлено через 14 минут

Сообщение от locm В ARM винде нормально запускаются приложения для x86 и режиме эмуляции.

Да ладно! Эмуляция же. Наверняка там тормознутая дичь. Это же ARM.
То что оно может подхватить ускорение вывода графики не спасает вычислительную часть.
Для простенького софта где упор на GPU - может и сойдёт, а так думаю в усреднённом случае
тормоза будут сильно заметны.

Добавлено через 11 минут

Сообщение от CoderHuligan Доупустим строка имеет размер 20 байт. Под размещение выделено 32 байта.

Я у себя эту технологию опробовал ещё в 14-м году. Очень простая, называется буферизация)))
Просто внедрил, даже не проверяя, ибо и так понятно что озвученный прирост будет.
Мотай на ус пока квит ещё живой.

Сообщение от CoderHuligan плюс выравнивание в степень двойки.

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

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

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

0

Сообщение от Quiet Snow Оно вообще того стоит?

Стоит если это делать под свой компилятор.

Сообщение от Quiet Snow Я GAS вот не хочу, ну его в попу

Там есть своя философия в корне отличная от masm. Я раньше тоже боялся этого монстра, одно название уже пугает, но постепенно привык.))

Сообщение от Quiet Snow Так бы и FASM сошёл, он прикольный,

У меня он тоже есть, как то примерчики запускал, но сильно не вникал. Знаю, что на нем операционку реализовали.

Сообщение от Quiet Snow А MASM дальше 5 версии под DOS превратился в лютое фуфло. А современные ещё надо из майкровских студий руками выцарапывать

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

Добавлено через 3 минуты

Сообщение от Quiet Snow И тут вопрос где ты больше просрёшь времени, на склеивании строк в обработчике(

Протестирую, там видно будет.

0

Сообщение от CoderHuligan Так что пока masm32 курю.

32 битки, надо конечно тоже охватывать, отдавая дань старым ОС, но делать это уже после 64 биток.
Masm 32 смотрел, там всё нормально, он вроде свободный открытый, правда слегка устаревший,
но деталей лицензии не помню, можно ли его применять у себя(всмысле распространять с любыми
своими решениями), тут вот не уверен, лицензию покури.

Добавлено через 9 минут

Сообщение от CoderHuligan Там есть своя философия в корне отличная от masm.

Это ассемблер))) какая там в жопу философия))) он почти всегда одинаковый. Всё вплоть до секций
мы и на масме забивали руками, что там такого нового? Куча ключей компиляции, ключей линкера. Да ну нафиг!
На мой взгляд лучше структуру exe-файла изучить, без философий, может даже и ассемблер
не понадобится, сделать ограниченный набор инструкций под компиль, чтобы это простенько
выглядело. Почему люди любят всё усложнять на ранних этапах и всё берут с чужих голов?
Своей головой надо педрить, иначе никуда ничего не двинется.

0

Сообщение от Quiet Snow 32 битки, надо конечно тоже охватывать, отдавая дань старым ОС, но делать это уже после 64 биток.

Я вот этот GAS курил как раз под 64. А 32 битки они по любому запустятся и на 32 и на 64 битных осях. Рано сдавать их в утиль.

Сообщение от Quiet Snow какая там в жопу философия)))

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

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

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

0

Сообщение от CoderHuligan А 32 битки они по любому запустятся и на 32 и на 64 битных осях.

Неа, не по-любому, местами пинками заводятся. Без тестинга заводятся не всегда, можно обосраться.
И дело не в битности, а в реализации API винды под эти битности, ну и в разных версиях конечно.
Обратная совместимость есть, но это скользкий момент в винде. Если с XP и до 10-ки - работает,
значит можно немного расслабить булки, но на этих системах тестить обязательно.
Я вот тут недавно хотел потестить прогу Braina, так вот она, сука, установилась(устанавливалась около часа),
сожрала 3Гб ценного мобильного трафика и выдала мне эррор, и вот невдомёк мудакам разрабам ПЕРЕД
установкой проверить системные требования, ОС, там GPU или что-то ещё и сразу отказать в установке,
нет откровенно гадят. Я постоянно про такое дерьмо говорю, но люди то кони, а не люди.

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

Нет мы про разные вещи говорим. Ты про слой над ассемблерами, а я про "микро"-асм,
ведь не секрет что 90% инструкций в большинстве случаев не используется. Покодить
основные моменты на асме, понять что используется. Заимплементить генерацию маш-кода.
Слой над асмами нужен вообще для другого, для например конвеерной оптимизации,
но зачем это делать сразу. Надо сначала чтобы хоть что-то компилилось. Даже если оно будет
хуже это уже будет твоё решение, заточенное под твои нужды. Вот в чём смысл.

1

Сообщение от Quiet Snow Да ладно! Эмуляция же. Наверняка там тормознутая дичь.

Чтобы это проверить запустил тестовый код в PB ARM64 и в PB x86. Разница в 2.7 раз.
Но сравнение не совсем корректное, т. к. сравнивался 32 и 64 бит машинный код, собранный разными компиляторами (x86 - GCC, ARM64 - шланг clang).
В любом случае, замедление в 3 раза это не худший результат эмуляции другой архитектуры и разрядности проца.

Если сравнить с моим компом то в однопотоке он быстрее малины в 10 раз. Но проц жрет около 80 Вт во время теста. Сколько жрет в малине не знаю, но проц вообще не имеет охлаждения (фотку малины можно увидеть в Вике) и слегка теплый. То есть потребляет не больше 2 Вт. Отсюда производительность ниже.

Сообщение от Quiet Snow Наверняка там тормознутая дичь. Это же ARM.

Почему ARM тормознутые?
Вполне нормальные и весьма энергоэффективные.

0