Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт мар 28, 2024 15:58

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 4 ] 

Разделять данные и код или нет?
Да, разделять 43%  43%  [ 3 ]
Нет, хранить все в одной куче 0%  0%  [ 0 ]
Использовать для каждой задачи оптимальное решение 57%  57%  [ 4 ]
Не знаю 0%  0%  [ 0 ]
Мне все равно 0%  0%  [ 0 ]
Опрос бессмысленный, а тему закрыть 0%  0%  [ 0 ]
Всего голосов : 7
Автор Сообщение
 Заголовок сообщения: Код и данные: разделять или нет?
СообщениеДобавлено: Вс окт 21, 2012 12:48 
Не в сети
Аватара пользователя

Зарегистрирован: Вт мар 20, 2007 23:39
Сообщения: 1261
Благодарил (а): 3 раз.
Поблагодарили: 19 раз.
Предлагаю обсудить преимущества и недостатки обоих подходов к хранению данных и кода на основе личного опыта. Не будем цитировать буквари, интернеты и прочее. Не будем подаваться в теории воздействия на программу пространственно-временного положения космических тел. Просто поделимся положительным и отрицательным опытом использования систем с разделением или не разделением данных и кода.

Разделение кода и данных считаю очень удобным решением.
+ Простые строковые литералы: числовой литерал для az-строк и двойной числовой литерал для a u строк;
+ Код не может быть поврежден в следствии переполнения или опустошения какого-то буфера;
+ Легко контролировать как размер кода и данных, так и размер выделяемых для них объемов памяти;
+ Данные можно легко хранить во внешнем файле — очень удобно для поддержки нескольких языков.
Еще тут подмалось, что можно было бы сделать отдельные буферы для констант, переменных, массивов и строк. С другой стороны, а как со всем этим работать в многопоточной системе?

Код и данные в одном буфере:
+ Вся система в одном буфере, которым управлять легче, чем когда их много;
- Специальный хитрый код для строковых литералов с изменением данных на стеке возвратов;
- Код может быть поврежден в следствии переполнения или опустошения какого-то буфера или процедурой обработки строк;
- Вызов апи с передачей строки теоретически может получить доступ к коду, что негативно сказывается на безопасности;
- Невозможно определить отдельно размер кода и размер данных;
- Усложняется поддержка многоязыковых строковых литеролв (самый простой вариант #язык CASE получился не очень красивым, сложноуправляемым и вообще неудобным).

_________________
Cтоимость сопровождения программного обеспечения пропорциональна квадрату творческих способностей программиста.
Роберт Д. Блисc


Последний раз редактировалось VoidVolker Вс окт 21, 2012 14:24, всего редактировалось 1 раз.

Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Код и данные: разделять или нет?
СообщениеДобавлено: Вс окт 21, 2012 14:16 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
VoidVolker писал(а):
Разделение кода и данных считаю очень удобным решением.

оно, решение чуточку более сложным получается - это минус.

VoidVolker писал(а):
+ Простые строковые литералы: числовой литерал для az-строк и двойной числовой литерал для a u строк;

совершенно не стоящая внимания выгода.

VoidVolker писал(а):
+ Код не может быть поврежден в следствии переполнения или опустошения какого-то буфера;

может, если адресное пространство одно (если память сегментированная, то +)

VoidVolker писал(а):
+ Легко контролировать как размер кода и данных, так и размер выделяемых для них объемов памяти;

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

VoidVolker писал(а):
+ Данные можно легко хранить во внешнем файле — очень удобно для поддержки нескольких языков.

это совершенно пофигу, тем более, что можно сразу создать необходимую структуру с необходимыми данными и сохранять только их(т.е. лучше отдельную конструкцию создать для этого.). Кстати, если взять, к примеру, СПФ, то именно в отдельной области хранятся пользовательские переменные (USER которые).

VoidVolker писал(а):
Еще тут подмалось, что можно было бы сделать отдельные буферы для констант, переменных, массивов и строк. С другой стороны, а как со всем этим работать в многопоточной системе?

вот как раз с помощью USER переменных и поддерживается многопоточность в СПФ и некоторых других системах.

Явным плюсом выделения кода в отдельное пространство на современных архитектурах будет ускорение работы за счет лучшего кэширования кода, не будет потерь при записи данных в код, из-за которых у того же СПФа есть потеря производительности. Кроме того, при сохранении отдельной программы часто не нужны имена, поэтому, если у системы код, данные, вспомогательные структуры типа имен слов и словарей можно просто не сохранять. Однако система с разделенными пространствами становится сложнее (больше примитивов для работы с памятью нужно). Ну и отлаживаться тоже сложнее чуток будет.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Код и данные: разделять или нет?
СообщениеДобавлено: Вс окт 21, 2012 14:31 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
VoidVolker писал(а):
Код и данные в одном буфере:

не пойму только причем тут буфер?

VoidVolker писал(а):
+ Вся система в одном буфере, которым управлять легче, чем когда их много;

да, именно так, об этом я сказал ранее. Просто значительно проще, и кроме того, меньше примитивов для работы с памят(ями).

VoidVolker писал(а):
- Специальный хитрый код для строковых литералов с изменением данных на стеке возвратов;

этого не понял.
Кстати, в Форте не всегда можно разделить код и данные (логически).

VoidVolker писал(а):
- Код может быть поврежден в следствии переполнения или опустошения какого-то буфера или процедурой обработки строк;

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

VoidVolker писал(а):
- Вызов апи с передачей строки теоретически может получить доступ к коду, что негативно сказывается на безопасности;

забей, в смысле вообще ни о чем.

VoidVolker писал(а):
- Невозможно определить отдельно размер кода и размер данных;

утверждение не верно.

VoidVolker писал(а):
- Усложняется поддержка многоязыковых строковых литеролв (самый простой вариант #язык CASE получился не очень красивым, сложноуправляемым и вообще неудобным).

не вижу смысла в утверждении.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Код и данные: разделять или нет?
СообщениеДобавлено: Пн окт 22, 2012 14:13 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Размещение кода и данных в одной области м. давать бОльше гибкости программам. И простую возможность самомодификации - м.б. важно в приложениях с ограниченнными ресурсами. А надежность м. повысить перестартовав из известной точки - например, перезагрузившись из ПЗУ/Флешки.
Если происходит сбой в программе - то программа с разделением кода и данных не будет работать точно так же, как и с совмещением. Весь вопрос в скорости восстановления. Разве что перезагрузка по сторожевому таймеру может быть чуть быстрее.

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 4 ] 

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 10


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB