Обсуждение Глагола

фев | МАР | апр
| 8 |
2011 | 2012 | 2013

1 captures 8 мар 12 - 8 мар 12 |

Close Help

# Обсуждение Глагола

← предыдущая следующая →
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

Д 25.10.08 19:52 570 | Тот же вопрос про все задачи, которые были убраны из отдела ОС - ПереместитьУказку, ЖдатьВвод, и так далее. Вместо них есть аналогичные задачи в ГОС, но, получается, что в Глаголе уменьшаются возможности по созданию консольных приложений?
Д 26.10.08 02:22 571 | > Предполагается, что разрядность видов ЦЕЛ и ВЕЩ равна разрядности процессора Я подумал - всё же по-моему это совершенно неправильно. Разрядность основных видов не должна зависеть от разрядности процессора. Ведь разрядность вида зависит от условий, предъявляемых самой задачей - наибольшего значения, которое может иметь переменная (для целочисленных видов), необходимой точности (для вещественных видов). Если, к примеру, в таком случае написать программу для 64-разрядного ПГ, а потом откомпилировать её на 32-разрядном, при работе произойдёт арифметическое переполнение, или недопустимая потеря точности. Скорее уж наоборот, можно в отделе ОБХОД, или в другом специальном встроенном отделе создать переменные, разрядность которых привязанна к разрядности процессора. Хотя незнаю, насколько и это нужно - я не могу придумать ни одной задачи, в которой это бы могло понадобиться.
Д 26.10.08 02:23 572 | А существуют ли какие-то технические ограничения на разрядность видов? То есть, можно ли создать 128-разрядные виды, например?
Сый 26.10.08 08:57 573 | 571. Весьма странно бы смотрелся вид ЦЕЛ 32-разрядный на 64- (или, тем более, на 128-) разрядной машине. По сути это было бы неэффективное использование возможностей процессора. Сами посудите: он, например, расчитан обрабатывать данные порциями по 128 битов, а мы ему больше 64-х (ШИРЦЕЛ для 32-разрядного процессора) дать не можем. В итоге то, что он бы сделал за 1 шаг, приходится выполнять за 2 как минимум. А на случай, если диапазон присваиваемых значений чётко определён, и созданы виды отдела ОБХОД.
Сый 26.10.08 09:00 574 | 572. Если сильно постараться, то можно и виды неограниченной разрядности сделать. Но врядли их внедрение и использование было бы оправданно.

Д
27.10.08 00:40

575

> А на случай, если диапазон присваиваемых значений чётко определён
Это так почти в любой задаче. То есть придётся либо всегда пользоваться отделом ОБХОД, что, по-моему неудобно, либо пользоваться тексторезом:

    <*ЕСЛИ ЗАДАНО(ПГ16) ТО> ЦЕЛ <*ИНАЧЕ*> ШИРЦЕЛ <*КОН*>

Что по-моему также не очень удобно. Наоборот, если есть какая-то задача, в которой допустимо использование как более узкого, так и более широкого числового вида, но использование более широкого при наличии 64-разрядного процессора может повысить производительность (я такую задачу придумать немогу), в ней можно используя тексторез писать разные куски программ для разных процессоров.
Виды надо выбирать в зависимости от требований задачи, а если процессор имеет большую разрядность он просто будет выполнять программу быстрее (32-разрядный процессор считает ШИРЦЕЛ за два раза, а 64-разрядный - за один).

Д 27.10.08 00:46 576 | > Если сильно постараться Вопрос как раз в том - это сложно сделать, или введение новых видов ограничивается только тем, чтобы не усложнять язык?
Сый 27.10.08 07:47 577 | > Это так почти в любой задаче. Отнюдь. Диапазон почти всегда предполагается очень приблизительно: чаще всего переменная задумывается либо как счётчик (ЯЧЦЕЛ или УЗКЦЕЛ), либо как вычисляемое значение или счётчик при чтении файла (ВЕЩ и ЦЕЛ), либо результат вычисления математического выражения (ШИРВЕЩ и ШИРЦЕЛ). Существует также множество других случаев употребления и факторов, влияющих на выбор вида. Но чтобы требовалась строго определённая разрядность, бывает весьма редко. Например, когда переменная используется не как число, а как участок памяти.

Сый
27.10.08 07:56

578

> писать разные куски программ для разных процессоров
Это было бы просто перегрузкой кода его повторением, а также демонстрацией непереносимости программ.
> Вопрос как раз в том - это сложно сделать, или введение новых видов ограничивается только тем, чтобы не усложнять язык?
Тут всё сразу. Это достаточно сложно сделать, работать это будет достаточно неэффективно, язык же будет перегружен новыми правилами и видами.

Д
28.10.08 00:15

579

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

← предыдущая следующая →
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

Сделано в России