Определить размер программы

[James DiGreze]

Если ее не отбрасывать, то придется сдвигать при изменении размера, что еще дольше, чем считать введенные/удаленные символы.

Вопрос: предполагается добавление текста не только в конец файла, или только в конец?

[AlexG]

Лежит у меня MCS-251. Там примерно так же - пара DPTR, адресация шире, RAM больше и по даташиту "До 15 раз быстрее обычных MCS-51". Кроме того, в примененном мною P80C32UFPN, оказывается, тоже пара DPTR. Но, так как я эту плату сделал как раз для изучения семейства, я об этих нюансах узнал лишь недавно. Переделывать под MCS-251 пока не хочется. Задрать частоту до допустимых 33МГц желание есть, но не уверен в работоспособности UART. Пока у меня автоопределение BAUDRATE. Кажись переписывать придется. Либо цеплять внешнюю 16C550 или Z8523016. И тех и других - горсть. Но всё не покидает чувство, что надо использовать проц, а не МК и не страдать фигней))) Останавливает только удобный монитор. Под Z80 я такого пока не нашел, не говоря уж о других процах.

- - - Добавлено - - -

И еще огромный запас P80C552EBA, 74HC573 и кварцев на 11,0592)))))

Лично мне не нравятся АРМ и еже с ними (звук не ламповый). 51 семейство обширное и много разных видов одного типаразмера (что дип что плсс - пин-то-пин), на асме писать просто. куча встроенной периферии + озу+флеш (не мегобайты - но всё же). Вот "сейчас" надо доработать программу 15-летней давности. 8кб кода на асме. Изделие работает по 24 часа 365 дней в году (утрировано).
семейство 251 загнулось на корню - его практически никто не "скопировал". а 51 живо и здорово нынче.

[alm604]

Конечно, добавление и удаление может быть в любой части памяти (файла).
Мне после AVR, STM тоже понравился 51-й. Особенно тем, что работает, как процессор. Пусть и с костылём (RD || PSEN)

[James DiGreze]

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

[alm604]

Офигеть! А про редактирование-то я вообще не думал, оказывается... Задача оказывается более сложной, чем кажется(

[James DiGreze]

Если изначально ввести ограничение на максимальный размер файла, всегда заведомо меньший объёму ОЗУ, то задача вполне посильная. И уж точно производительности "полстапервого" с кварцем "110592" вполне за глаза.

[Advertiser]

[ram_scan]

Задача на самом деле тривиальная.
Часть текста до курсора хранится в начале памяти, часть после - в конце. Посередине дырка.
Текст на экране отрисовывается от курсора вниз, и от курсора вверх. Вставка текста происходит в дырку. При навигации по тексту дырка перемещается вместе с курсором. При добавлании - добавляется в начало дырки, и дырка уменьшается, при удалении символов - дырка увеличивается.

Всего геморроя - указатель на начало текста, указатель на конец текста, указатель на начало дырки, указатель на конец дырки. Ну и при навигации дырку эту правильно по памяти возить (перекидывать порции текста из начала дырки в конец и обратно). Поскольку человек жмет кнопки гораздо медленнее чем процессор работает, а дальше чем на один экран зараз листать текст нет смысла, то все работает очень шустренько. Медленно только в начало и в конец документа переход будет работать, там надо дырку далеко двигать и много данных перемещать. Но это операция нечастая.

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

[alm604]

Вся проблема в том, то оперативы у 51-го маловато. Просто указатели я хранить постоянно не могу - DPTR всего два и то, это далеко не у всех 51-ых. Можно хранить в регистрах и подгружать в DPTR при необходимости, конечно, но это дополнительные телодвижения. Короче, я попробую. По-любому вопросы возникнут - напишу)

[blackmirror]

alm604, два DTPR это более чем достаточно, с одним DTPR конечно придётся сначала пройтись по начальной или конечной половине текста, чтобы выяснить сколько байт нужно копировать, а затем уже копировать заталкивая по нескольку байт в стек или регистры. Вообще при прокрутке назад всё равно сначала нужно узнать сколько символов в предыдущей строке чтобы правильно выставить курсор в случае когда длина предыдущей строки больше ширины экрана. Хотя от предварительного прохода назад можно избавиться если вместо символа перевода строки в начальном блоке хранить длину строки перед символом перевода, а в конечном блоке длину строки после символов перевода, для текущей строки разумеется должна быть известна длина до и после курсора. Такой вариант позволит при предварительном проходе для прокрутки на одну строку или страницу не просматривать каждый символ строки а вычислить копируемую область на основе длин строк.

[James DiGreze]

Даже одного DPTR более чем. Просто не нужно стесняться делать "телодвижения" - производительности хватит за глаза.