Лично мне не нравятся АРМ и еже с ними (звук не ламповый). 51 семейство обширное и много разных видов одного типаразмера (что дип что плсс - пин-то-пин), на асме писать просто. куча встроенной периферии + озу+флеш (не мегобайты - но всё же). Вот "сейчас" надо доработать программу 15-летней давности. 8кб кода на асме. Изделие работает по 24 часа 365 дней в году (утрировано).
семейство 251 загнулось на корню - его практически никто не "скопировал". а 51 живо и здорово нынче.
Конечно, добавление и удаление может быть в любой части памяти (файла).
Мне после AVR, STM тоже понравился 51-й. Особенно тем, что работает, как процессор. Пусть и с костылём (RD || PSEN)
Тогда в любом случае идёт довольно обширное копирование внутри памяти.
Почитай тему Как организовать память для текстового редактора?. В зависимости от подхода к организации памяти будет понятно, как эффективнее определять размер получившегося файла.
Офигеть! А про редактирование-то я вообще не думал, оказывается... Задача оказывается более сложной, чем кажется(
Если изначально ввести ограничение на максимальный размер файла, всегда заведомо меньший объёму ОЗУ, то задача вполне посильная. И уж точно производительности "полстапервого" с кварцем "110592" вполне за глаза.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Задача на самом деле тривиальная.
Часть текста до курсора хранится в начале памяти, часть после - в конце. Посередине дырка.
Текст на экране отрисовывается от курсора вниз, и от курсора вверх. Вставка текста происходит в дырку. При навигации по тексту дырка перемещается вместе с курсором. При добавлании - добавляется в начало дырки, и дырка уменьшается, при удалении символов - дырка увеличивается.
Всего геморроя - указатель на начало текста, указатель на конец текста, указатель на начало дырки, указатель на конец дырки. Ну и при навигации дырку эту правильно по памяти возить (перекидывать порции текста из начала дырки в конец и обратно). Поскольку человек жмет кнопки гораздо медленнее чем процессор работает, а дальше чем на один экран зараз листать текст нет смысла, то все работает очень шустренько. Медленно только в начало и в конец документа переход будет работать, там надо дырку далеко двигать и много данных перемещать. Но это операция нечастая.
При выгрузке документ просто склеивается из двух кусков, чтобы дырки не было.
Последний раз редактировалось ram_scan; 25.11.2016 в 11:03.
Вся проблема в том, то оперативы у 51-го маловато. Просто указатели я хранить постоянно не могу - DPTR всего два и то, это далеко не у всех 51-ых. Можно хранить в регистрах и подгружать в DPTR при необходимости, конечно, но это дополнительные телодвижения. Короче, я попробую. По-любому вопросы возникнут - напишу)
alm604, два DTPR это более чем достаточно, с одним DTPR конечно придётся сначала пройтись по начальной или конечной половине текста, чтобы выяснить сколько байт нужно копировать, а затем уже копировать заталкивая по нескольку байт в стек или регистры. Вообще при прокрутке назад всё равно сначала нужно узнать сколько символов в предыдущей строке чтобы правильно выставить курсор в случае когда длина предыдущей строки больше ширины экрана. Хотя от предварительного прохода назад можно избавиться если вместо символа перевода строки в начальном блоке хранить длину строки перед символом перевода, а в конечном блоке длину строки после символов перевода, для текущей строки разумеется должна быть известна длина до и после курсора. Такой вариант позволит при предварительном проходе для прокрутки на одну строку или страницу не просматривать каждый символ строки а вычислить копируемую область на основе длин строк.
Даже одного DPTR более чем. Просто не нужно стесняться делать "телодвижения" - производительности хватит за глаза.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)