Важная информация
Страница 1 из 4 123 ... ПоследняяПоследняя
Показано с 1 по 10 из 36

Тема: Windows-степлер: Разработка

  1. #1 Windows-степлер: Разработка 
    Супер модератор Аватар для Kakos_nonos
    Регистрация
    07.01.2011
    Адрес
    Кубань
    Сообщений
    1,531
    Сказал(а) спасибо
    126
    Поблагодарили 428 раз(а) в 291 сообщениях
    Записей в блоге
    6
    Уже давно вынашиваю в голове идею степлера под Windows. Пока до реализации далеко, но можно обсудить некоторые вопросы, сформулировать структуру.

    Какие есть пожелания:
    1. Сделать ячейки 32-х битными. Это нам позволит и выделять больше памяти и оперировать большими числами.
    2. Новый тип работы со строками. Это я в форте подсмотрел, когда мы введём $(3)('ololo'), то буквы не будут идти в ячейки 3,4,5,6, вместо этого где-то в памяти выделится место, туда запишется ололо, а в 3-ю ячейку пойдёт адрес этого места в памяти.
    3. Поддержка окон, событий. Я пока плохо представляю как это сделать, но это возможно.
    4. Поддержка DLL. Это, наверное, самый важный пункт. Если мы сможем подключать dll-и, то возможности степлера будут практически безграничны. Можно будет 3-ий пункт тоже через dll-и реализовать, если это возможно. И вообще, хочется сделать ядро как можно меньше, чтоб всё было в библиотеках. Также потребуется разработать команды для связи dll и степлер программы.

    Давайте обсудим это дело, может что-то и выйдет
    [Ссылки могут видеть только зарегистрированные пользователи. ]
    Ответить с цитированием  
     

  2. 2 пользователя(ей) сказали cпасибо:


  3. #2  
    Модератор Аватар для pingvin
    Регистрация
    11.02.2011
    Сообщений
    389
    Сказал(а) спасибо
    80
    Поблагодарили 75 раз(а) в 48 сообщениях
    Я бы пожелал, чтобы писали на кроссплатформенных средах программирования. Тогда ещё больше людей могли бы приобщиться к идее.
    На этом месте могло быть Ваше "Спасибо"
    Ответить с цитированием  
     

  4. Пользователь сказал cпасибо:


  5. #3  
    Гуру Аватар для Абадябер
    Регистрация
    09.12.2010
    Адрес
    Беларусь, Минск
    Сообщений
    1,219
    Сказал(а) спасибо
    302
    Поблагодарили 176 раз(а) в 144 сообщениях
    Записей в блоге
    5
    Цитата Сообщение от pingvin Посмотреть сообщение
    Я бы пожелал, чтобы писали на кроссплатформенных средах программирования
    Тут следует различать два момента. Можно делать кодогенератор (в случае, если мы делаем полноценный компилятор) под несколько ОС\платформ. В таком случае, даже обладая компилятором под Windows работающим, можно будет им генерировать код хоть под андроиды.
    Ну и да, можно сделать компилятор работающим на нескольких платформах. Это особенно будет полезно, если делать интерпретатор, типа как был в LINT, с вшитием баткода в файл. Тут уже без кроссплатформы будет никак.
    Но нужно понимать, что сервисы работы с DLL распространяются только под винду, о чем напоминает капитан Очевидность. Если нацеливаться на кроссплатформенность, есть смысл сначала сделать стандартную библиотеку языка, и ее реализации под все планируемые платформы. Это минимум, который позволит языку быть кроссплатформенным.

    1. 32-битные ячейки - это обязательно, как само собой разумеющееся. Оптимально с точки зрения 32-битной платформы, удобно и просто разумно.
    2. Идея отличная, между прочим, мы, когда программировали на степлере, то все были близки к этой идее, когда делали что-то вроде 5$$
    Но есть нюансы. Как бы по природе языка, которая у нас все таки стековая (точнее, справедливости ради, степлер только косит под стековый язык, по настоящему от стековых языков у него только стек выражений ОПЗ, все остальное - лютая императивщина и структурщина (функции, процедуры, локальные переменные и.т.п, там найдется)) может быть полезным крутить строки тоже на стеке. Так что вопрос остается открытым. Как бы с одной стороны иногда строкам и есть смысл храниться не в стеке, если для них нужно просто вызвать пару функций (например, объединение и запись в файл), но это противоречит природе самого языка. Как вариант, для этой задачи можно просто добавить функцию, типа "затолкнуть строку по такому-то адресу в стек".
    Память для строк можно выделять из динамической. Прелесть Windows в том, что она будет давать память нашей программе до последнего, поэтому никаких проблем с выделением памяти хоть для 200 сотен строк не возникнет. Но этот метод опасен возникновением уточек памяти. Т.е, придется следить за тем, чтобы вовремя освобождать ставшие ненужными участки памяти. Из плюсов - удобство реализации, это довольно просто, но этот вариант грозит фрагментацией памяти. Не так критично для современных систем, когда памяти в среднем уже по 2-4Гб у людей, но все равно. Оптимизация - наше все
    Есть другой вариант. Можно сделать банальную директиву в языке. Типа MemReq N. Где вместо N - количество байт\килобайт памяти, которая понадобится программе. Программист тогда сам должен будет следить за тем, сколько он потребляет, и выделять соответственное количество этой директивой. В начале работы программы все запрошенной количество выделяется единым непрерывным куском. Там могут располагаться не только строки, но и переменные, и что еще душа пожелает. Подобный способ я применил в своей расширенной версии степлера для игрового движка, который загнулся, увы. Ну и придется сделать мини-менеджер памяти, который будет из этого огромного куска по запросу программы на выделение для чего-либо памяти, выделять ему кусочек и возвращать на него указатель. Но вот с освобождением памяти будут некоторые трудности. Придется запоминать, какие участки памяти у нас в настоящий момент свободны, а какие заняты. Это можно сделать с помощью массива из байт, например, где каждый бит будет по факту означать занятость или свободность того или иного байта общей памяти (или ячейки, если мы будем делить память именно по ячейкам, тогда контрольный блок будет занимать аж в 32 раза меньше места, чем блок памяти). Недостатки очевидны - сниженное быстродействие, небольшой дополнительный расход памяти, сложности реализации.
    3. На уровне той же стандартной библиотеки языка, которую просто нужно согласовать и реализовать. Реализуем несколько функций по принципу тех, что есть в WinAPI. Можно с более высоким уровнем абстракции, например, внутри вызванной функции степлера CreateWindow(аргументы) могут происходит несколько вызовов функций WinAPI сразу. Опять же, этот вариант может быть вполне портируем в пределах нескольких ОС, т.к достаточно для другой системы просто будет переписать библиотеку языка.

    Кстати, у меня вопрос по поводу структуры памяти. Она у нас планируется ячеистой, или же байтовой? Первый вариант более простой, второй - более гибкий.
    Дружба-магия-радость!
    Ответить с цитированием  
     

  6. 2 пользователя(ей) сказали cпасибо:


  7. #4  
    Супер модератор Аватар для Kakos_nonos
    Регистрация
    07.01.2011
    Адрес
    Кубань
    Сообщений
    1,531
    Сказал(а) спасибо
    126
    Поблагодарили 428 раз(а) в 291 сообщениях
    Записей в блоге
    6
    Цитата Сообщение от pingvin Посмотреть сообщение
    Я бы пожелал, чтобы писали на кроссплатформенных средах программирования. Тогда ещё больше людей могли бы приобщиться к идее.
    Это да, хорошо было бы. Но, думаю, сначала надо сделать Windows-версию, на ней всё отработать, потом переходить на другие платформы.
    Можно использовать яву, тогда программы можно будет запускать почти везде, в том числе и на андроидах.

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

    Структура памяти будет ячеистой, но можно будет и к байтам обращаться. Помимо команды $ будет команда ` , которая будет читать из памяти (в ней будет находится не адрес ячейки, а адрес в памяти). Также думаю сделать для неё ещё один переметр - количество байт, которые надо брать из памяти.
    Код будет выглядеть вот так:

    $(4)(5$^2`)

    Это значит "Поместить в 4-ую ячейку 16-битное число из динамической памяти, адрес расположен в пятой ячейке"

    Можно и обратно:

    `(5$^2)(4$)

    У нас для этого уже была команда M для пересылки памяти, но мне кажется так удобнее.

    Интерпретация скорее будет через байткод, его можно приписывать к интерпретаторам и получать exe. Так же и для других платформ.
    [Ссылки могут видеть только зарегистрированные пользователи. ]
    Ответить с цитированием  
     

  8. Пользователь сказал cпасибо:


  9. #5  
    Супер модератор Аватар для >Quiet Snow<
    Регистрация
    11.04.2011
    Адрес
    Планета земля
    Сообщений
    3,878
    Сказал(а) спасибо
    1,829
    Поблагодарили 957 раз(а) в 816 сообщениях
    Записей в блоге
    1
    Но, думаю, сначала надо сделать Windows-версию
    Имхо, винды хватит выше крыши. Однако много какие компилеры сейчас уже и под линукс как минимум есть.
    Это к слову о том, на чём будет написан транслятор(а может быть уже и сразу компилятор).
    Обучение прикладному программированию(по skype), качественно, недорого, 18+, вопросы в личку.
    «Если вы ничего не сделаете, я уверяю вас, ничего и не произойдёт» © Жак Фреско
    Ограниченно модерирую.
    Ответить с цитированием  
     

  10. #6  
    Супер модератор Аватар для >Quiet Snow<
    Регистрация
    11.04.2011
    Адрес
    Планета земля
    Сообщений
    3,878
    Сказал(а) спасибо
    1,829
    Поблагодарили 957 раз(а) в 816 сообщениях
    Записей в блоге
    1
    сделать стандартную библиотеку языка, и ее реализации под все планируемые платформы
    Посмотрите как сделано в PB. Под каждую платформу написана библиотека формата этой платформы с
    одинаковыми функциями. И код легко переносится с одной платформы на другую, если не содержит API
    конкретной платформы. Т.е. на выходе транслятора имеем ASM файлик с кроссплатформенными функциями,
    который cкармливается ассемблеру для получения исполняемого файла.

    но этот вариант грозит фрагментацией памяти.
    Да и это печально. На XP память течёт будь здоров, если хаотично резервировать. На других виндах не проверял,
    думается полностью убрать фрагментацию нельзя, это естественный процесс при резервировании памяти.

    Ну и придется сделать мини-менеджер памяти
    И тут мозг начинает понимать, что, , , напрягается.

    Она у нас планируется ячеистой, или же байтовой?
    Народ, а если вся засада только со строками, то может стоит пересмотреть архитектуру ЯП?
    Допустим разработать функции в ЯП, которые автоматически будут работать со строками
    и укладывать их в 32битные ячейки. Т.е. в одной ячейке 4 символа ASCII\UTF. Будет фрагментация
    да небольшая, но это всё фигня. Главное, чтобы программа "знала", где находятся эти строки
    и не затирала их чем-либо. Можно юзать формат STRINGZ, а первым DWORD-ом хранить длину строки.
    Обучение прикладному программированию(по skype), качественно, недорого, 18+, вопросы в личку.
    «Если вы ничего не сделаете, я уверяю вас, ничего и не произойдёт» © Жак Фреско
    Ограниченно модерирую.
    Ответить с цитированием  
     

  11. #7  
    Супер модератор Аватар для Kakos_nonos
    Регистрация
    07.01.2011
    Адрес
    Кубань
    Сообщений
    1,531
    Сказал(а) спасибо
    126
    Поблагодарили 428 раз(а) в 291 сообщениях
    Записей в блоге
    6
    А как вам идея реализовать трансляцию степлера в другой язык, например FB, а он уже будет компилировать в exe.
    Так мы получим хорошую функциональность, расширяемость, производительность.
    Основная проблема будет в реализации строк с ОПН, но их можно интерпретировать, а может и написать конвертер в инфиксную нотацию.
    [Ссылки могут видеть только зарегистрированные пользователи. ]
    Ответить с цитированием  
     

  12. #8  
    Супер модератор Аватар для Kakos_nonos
    Регистрация
    07.01.2011
    Адрес
    Кубань
    Сообщений
    1,531
    Сказал(а) спасибо
    126
    Поблагодарили 428 раз(а) в 291 сообщениях
    Записей в блоге
    6
    Можно ещё форт использовать в качестве промежуточного языка, но в нём нет операции GOTO, хотя её можно реализовать, обдумываю.
    [Ссылки могут видеть только зарегистрированные пользователи. ]
    Ответить с цитированием  
     

  13. #9  
    Супер модератор Аватар для >Quiet Snow<
    Регистрация
    11.04.2011
    Адрес
    Планета земля
    Сообщений
    3,878
    Сказал(а) спасибо
    1,829
    Поблагодарили 957 раз(а) в 816 сообщениях
    Записей в блоге
    1
    например FB
    Можно в FreePascal, я видел там в настройках компилятора 3 уровня оптимизации, целевую оптимизацию под > Pentium4.
    + можно поотрубать все проверки. Степлеру нужна скорость.
    Можно и на FB конечно, классический бейсик-код читать попроще будет, там вродеб тоже есть опции оптимизации.
    Народ тогда сможет подглядеть как такие штуки реализуются. Работает он впринципе быстро и если честно не сравнивал
    FP и FB на чём-то реальном и тяжёлом. В случае чего и там и там можно подрихтовать ассемблером. FB даже на выходе
    может асм выдать для GAS. Тут ещё есть аспект кроссплатформенности языка в который транслируем, FB это винда и линукс,
    но линукс там как-то слабо поддерживают насколько я понял, в Паскале дела по линуксу должны быть лучше.
    Можно в PB, тогда ещё и Mac добавится. Ну или в QB64, там вроде можно экспортировать в java проект eclipse, будет тогда
    и android(правда цепочка такая нехилая выходит, морока для кодера). Также по доступности желательно СПО.

    Ещё хотел заметить, что раз уж под винду пишется, мол уже для более менее серьёзного использования, то можно
    проанализировать, где есть места, которые можно было бы оптимизировать потоками, либо SIMD-командами.
    Даже если СТЕПЛЕР сам по себе будет не намного быстрее предыдущих версий, то с данными оптимизациями
    определённо будет прогресс. Так сказать "в ногу со временем"...

    Ещё хочу добавить, что ежели будет *.dll или статика, то не исключаю вариант что-нибудь написать для степлера.
    Можно даже приколоться, засунуть в dll обёртку кучу библиотек с FB и "порулить" на СТЕПЛЕРЕ. Тут конечно должна
    быть совместимость по передаче параметров.
    Обучение прикладному программированию(по skype), качественно, недорого, 18+, вопросы в личку.
    «Если вы ничего не сделаете, я уверяю вас, ничего и не произойдёт» © Жак Фреско
    Ограниченно модерирую.
    Ответить с цитированием  
     

  14. #10  
    Супер модератор Аватар для Kakos_nonos
    Регистрация
    07.01.2011
    Адрес
    Кубань
    Сообщений
    1,531
    Сказал(а) спасибо
    126
    Поблагодарили 428 раз(а) в 291 сообщениях
    Записей в блоге
    6
    Продумал в голове алгоритм перевода степлер программ в форт, получается довольно интересно. Вначале программа будет транслироваться в некий код, который будет содержать в себе оттранслированный код степлера + компилятор, потом этот форт - код будет запускаться и сам компилироваться, давая на выходе exe.
    В итоге получаем:
    * Компактность.
    Компилятор форта весит 100 кб, программы на выходе тоже не очень большие. Если транслировать в FB, то придётся таскать с собой весь FB, а это не так уж мало.

    * Скорость.
    Поскольку это будет не совсем интерпретатор байткода и не совсем компилятор, то скорость будет выше чем при интерпретации байткода, но ниже чем при компиляции в асм. Но и это не плохо, по моему.

    * Кроссплатформенность.
    Форт-системы есть для всех платформ, даже для микроконтроллёров. Надо только написать стандартную библиотеку.

    * Расширяемость.
    В степлер код можно будет делать фортовые вставки, а возможность форта безграничны, то есть он позволяет вызывать dll и Winapi и прочие функции работы с системой.

    Пришла ещё пара идей:

    Мы помечали процедуры как ={}=, а метки как {}. Оба обозначения работали одинаково, не было между ними различия. Но я придумал, как можно их использовать: В подключаемых файлах (.suf) метки, которые видны извне описываьт как ={}=, а которые не видны - {}. Таким образом мы получаем также и решение проблемы с совпадением имён меток в различных модулях.

    Ещё можно сделать публичные и локальные DEFINE. Пусть будет так - публичные - PDEFINE. Локальные - DEFINE.

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

    $(3)(4$)
    $(7)(5)
    #(3$)<goto>

    $(6)(8)
    $(2)(4^5+)

    {goto}
    $(5)(9)
    $(7)(99)


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

    Код :
    : block1 ... ;
    : block 2 ... ;
    : block 3 ... ;

    А вот сама последовательность блоков будет интерпретироваться. Код для интерпретатора блоков будет содержать такие инструкции:
    0 - выполнить блок по адресу n
    1 - выполнить блок по адресу n и если результат выполнения истенен, перейти к позиции m
    2 - выполнить блок по адресу n и если результат выполнения истенен, вызвать процедуру с позиции m
    3 - выйти из процедуры
    4 - конец программы

    Блок может иметь результат, если последней операцией в нём является или операция перехода или операция выхода из процедуры. Также тут есть понятия: адрес и позиция. Адрес - это адрес откомпилированного блока в памяти, а позиция - это позиция в массиве в котором находится программа для интерпретатора (та команды 0 - 4). То есть программа и последовательность её выполнения находятся в разных местах.

    Выходная форт программа будет иметь такой вид:

    Код :
    : block1 ... ;
    : block2 ... ;
    : blockn ... ; (код всех блоков)
     
    create prog_code 
    0 , ' block1 ,
    0 , ' block2 ,
    1 , ' block3 , 2 ,    (создаём в памяти массив из последовательность кодов. Операция ' block возвращает адрес процедуры ) 
     
    : interpreter ...  ; (код интерпретатора. Он пишется позже, так как к нему на вход поступает уже готовый массив кодов )
     
    interpreter to <MAIN> 
    S" file.exe" SAVE  (сохраняем форт систему с главной процедурой interpreter)

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

    Есть какие-то предложения?
    [Ссылки могут видеть только зарегистрированные пользователи. ]
    Ответить с цитированием  
     

  15. Пользователь сказал cпасибо:


Страница 1 из 4 123 ... ПоследняяПоследняя
Информация о теме
Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Ответов: 1
    Последнее сообщение: 02.12.2014, 15:27
  2. СТЕПЛЕР-СЕРВЕР
    от Kakos_nonos в разделе Степлер
    Ответов: 4
    Последнее сообщение: 01.08.2014, 14:47
  3. Степлер-компьютер.
    от Kakos_nonos в разделе Микроконтроллеры
    Ответов: 9
    Последнее сообщение: 06.04.2014, 20:30
  4. Книга: СТЕПЛЕР. Язык программирования.
    от Kakos_nonos в разделе Степлер
    Ответов: 12
    Последнее сообщение: 23.03.2013, 06:43
  5. Компилятор BrainFuck на СТЕПЛЕР-е
    от Абадябер в разделе Проекты на Степлере
    Ответов: 4
    Последнее сообщение: 24.01.2012, 03:10
Ваши права
  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •