Вверх ↑
Этот топик читают: Гость
Администрация
Ответов: 15295
Рейтинг: 1519
#46: 2007-06-28 14:24:47 ЛС | профиль | цитата
tsdima писал(а):
А если бы это было число и bitmap, например?

в том-то весь и фокус, что именно в данном примере при данном подключение самое разумное поставить тип стринг. Я тоже предложил сначала variant пока коллега Galkov, не показал, что при типе string мы обойдемся всего одной вставкой int2str(), что вроде бы с точки зрения кода вполне логично: при такой оптимизации мы один раз пишем сразу в память, два раза сразу читаем из памяти и только один раз производим конвертацию. Если CG по некоторым критериям самостоятельно будет принимать такие решения, то можно говорить, что сгенерировать код лучше, чем это делаем мы практически невозвожно
карма: 27
0
Ответов: 2125
Рейтинг: 159
#47: 2007-06-28 14:27:14 ЛС | профиль | цитата
Dilma писал(а):
сгенерировать код лучше, чем это делаем мы практически невозвожно

Кто мешает учесть это в HubEx? Если на входах число и строка - выдавать строку
карма: 1

0
Администрация
Ответов: 15295
Рейтинг: 1519
#48: 2007-06-28 14:54:19 ЛС | профиль | цитата
рано торопиться. Пока обедал в голову пришел контр пример:
code_1606.txt

вопрос: какого типа должен быть memory? ответ вроде бы очевидный: string.
Теперь дополним этот пример одним элементом:
Add(Button,2600237,133,168)
{
Left=20
Top=20
Caption="2"
Data=String(ÔÔÔ)
link(onClick,8954093:doWork1,[(200,174)])
}
Add(Memory,12744181,231,217)
{
}
Add(Button,15280527,133,217)
{
Left=20
Top=20
Caption="2"
Data=String(ÔÔÔ)
link(onClick,8954093:doWork2,[])
}
Add(Button,14010558,133,266)
{
Left=20
Top=20
Caption="2"
Data=String(ÔÔÔ)
link(onClick,8954093:doWork3,[(200,272)])
}
Add(HubEx,8954093,196,210)
{
link(onEvent,12744181:doValue,[])
}
Add(Button,10262314,133,315)
{
Left=130
Top=325
link(onClick,8688004:doFor,[])
}
Add(Math,5513068,231,315)
{
Op2=1
link(Op1,12744181:Value,[])
}
Add(For,8688004,182,315)
{
End=10000
link(onEvent,5513068:doOperation,[])
}
ну, а кого типа Memory должен быть теперь и следующий вопрос: откуда CG узнает об этом Одним словом - думать еще и думать

[size=-2]------ Добавлено в 14:54
PS: между прочим эту тему nesco создавал вовсе не для выслушивания теорий оптимальной когогенерации...
карма: 27
0
файлы: 1code_1606.txt [708B] [675]
Ответов: 9906
Рейтинг: 351
#49: 2007-06-28 15:01:40 ЛС | профиль | цитата
tsdima, ты прав, если рассуждать ТОЛЬКО "вперед"

Все дело в этом "если".
А не обязан я рассуждать только так.
Скажи, если мы будем забирать с variant ТОЛЬКО string - за каким лядом хранить в другом формате

Нафига мне делать копию с bitmap-а (предположим), если потом мне надо будет превратить в пустую строку. Или в нулевое число...

Целью примера была демонстрация того, что знание "вперед" имеет прямой выход на эффективность кодов.
Кстати говоря, и конверторы типов, в случае Ex-а надо генерировать ДО парсинга метода, а не после.
Опять неоходимо знание "вперед"

Т.е., я делаю совершенно другой вывод: не вариантный тип нам нужен больше, а механизм получения этого знания
карма: 9

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#50: 2007-06-28 15:03:04 ЛС | профиль | цитата
Dilma, А что, надо создать отдельный топик -- Теория оптимальной когогенерации Будет весьма поучительно. Но про хождение разных типов данных по потокам -- это очень интересно.
карма: 22

0
Ответов: 9906
Рейтинг: 351
#51: 2007-06-28 15:08:43 ЛС | профиль | цитата
Dilma писал(а):
вопрос: какого типа должен быть memory? ответ вроде бы очевидный: string

А вот для меня очевидным был другой ответ - Real
Потому что я всегда больше любил рассуждать "с заду"
карма: 9

0
Ответов: 2125
Рейтинг: 159
#52: 2007-06-28 15:47:04 ЛС | профиль | цитата
Galkov писал(а):
если рассуждать ТОЛЬКО "вперед"

"вперед" - это не только линки слева направо, но и снизу вверх Так что - только вперёд!

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

[size=-2]------ Добавлено в 15:47
Здесь я имел ввиду, что генерация делается в два этапа:
1. Определение типов точек (тут и возможно откладывание "на потом").
2. Собственно генерация кода, где откладывать уже ничего нельзя.
карма: 1

0
Ответов: 9906
Рейтинг: 351
#53: 2007-06-28 16:08:56 ЛС | профиль | цитата
Ну вот, начинается

Изобрел двухпроходной способ компиляции

И это говорит человек, который знает за сколько проходов справляется FASM.
И насколько там сильна много-проходность.

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

И как-то же они там разбираются, чего делать на первом проходе, если параметр еще не определен, а какой-нибудь if его уже просит...
Посмотреть надо...
Я когда-то в своих листаниях исходников, только парсинг изучил...
карма: 9

0
Ответов: 2125
Рейтинг: 159
#54: 2007-06-28 17:16:31 ЛС | профиль | цитата
Galkov писал(а):
И это говорит человек, который знает за сколько проходов справляется FASM

Да, есть в этом что-то общее. Между прочим, первые макроассемблеры тоже были двухпроходными.
карма: 1

0
Ответов: 9906
Рейтинг: 351
#55: 2007-06-28 18:27:54 ЛС | профиль | цитата
Но даже TASM - уже больше
Много, в смысле
карма: 9

0
Администрация
Ответов: 15295
Рейтинг: 1519
#56: 2007-06-28 20:42:26 ЛС | профиль | цитата
tsdima писал(а):
Между прочим, первые макроассемблеры тоже были двухпроходными.

ну интересно, а как ты иначе джампы вперед обработаешь Ассемблер по определению быть однопроходным не может. Разве, что запретить начисто положительные смещения...
карма: 27
0
Ответов: 9906
Рейтинг: 351
#57: 2007-06-28 21:13:16 ЛС | профиль | цитата
Dilma писал(а):
а как ты иначе джампы вперед обработаешь

посмотри на коды FPC - увидишь
карма: 9

0
Администрация
Ответов: 15295
Рейтинг: 1519
#58: 2007-06-28 21:31:19 ЛС | профиль | цитата
Galkov писал(а):
посмотри на коды FPC - увидишь

Откопал свое раннее творение под названием Boot Pascal - язык для написание операционных систем. Так у меня без оптимизаций код лучше, чем у них генерится:

Program Project;

uses Vesa,System, Bios;

var i,j,p:word;
color:TColor;

begin
if i > j then
begin
p := i + j
end;
for i := 0 to 640-1 do
for j := 0 to 480-1 do
p := i + j;
readkey
end.

ASM:

.data

i dw 0
j dw 0
p dw 0
.code
start:
; if i > j then
xor ebx,ebx
mov bx,[j]
cmp [i],bx
jle @@if0

; p := i + j
xor ebx,ebx
mov bx,[i]
add bx,[j]
mov [p],bx

@@if0:
; for i := 0 to 640-1 do
mov [i],0
@@for0:
cmp [i],639
jg @@for1

; for j := 0 to 480-1 do
mov [j],0
@@for2:
cmp [j],479
jg @@for3

; p := i + j;
xor ebx,ebx
mov bx,[i]
add bx,[j]
mov [p],bx

inc [j]
jmp @@for2
@@for3:
inc [i]
jmp @@for0
@@for1:
; readkey
sub esp,1
mov ebx,esp
push ebx
call @@readkey
add esp,1

end start

;--------------------------------
@@readkey proc near
push ebp
mov ebp,esp

mov ah,0h
int 16h
mov ebx,[dword ptr ebp + 6]
mov [ byte ptr ebx ],al

pop ebp
ret 4
endp @@readkey

;--------------------------------
end

красота Добавить бы туда классы и можно было свой компилятор прикрутить.

[size=-2]------ Добавлено в 21:31
А вот так на нем выглядел ранее упоменаемый лоадер размером 512 байт:

{      MINI Boot Loader
  Минимальный загрузчик для 2х физических 
дисков. Он грузит НЕ ОС!, а всего лишь их
стандартные загрузчики, записанные в MBR
винчестера.
В программу не включены никакие проверки
ввода, поскольку 512 байт для такой роскоши
мало и пришлось бы делать 2х этапный
загрузчик.
}
program Hello;
{стандартное начало для Boot загрузчика}
{$ boot }
uses
System,bios;
var b:byte;
begin
{инициализируем сегмент данных}
initds
{переменная b отлична от 0 при повторном
вызове программы( ниже по тексту )}
if b
{подробнее о загрузке см. Помощь -> Загрузка }
bootfromdisk(b-1)
else
begin
clrscr
gotoxy(10,10)
writecstring("Demon Boot Loader:",clgreen)
{убрал, т.к. включение ещё какого либо
сделает размер загрузчика больше, чем
512 байт!}

{gotoxy(5,10)}
writecstring("1 - LILO ",clgray)
{gotoxy(5,11)}
writecstring("2 - Windows XP",clgray)
b := ReadKey - '0';
{грузим свою копию в новое место}
absread($1000,$7c00,1,1)
__ax := $1000
__es := __ax
{говорим ей, что пора грузить ОС}
asm
mov al,[cs:b]
mov [es:b],al
end
CallFarProc($1000,$7c00);
end
end.

- если бы в настоящее время такие штуки хоть сколько-нибудь были актуальны, можно бы было пределать как пакет к HiAsm.
карма: 27
0
Администрация
Ответов: 15295
Рейтинг: 1519
#59: 2007-06-29 16:36:21 ЛС | профиль | цитата
FTCG

Добавлена возможность вставки пользовательских типов:

регистрация типа из direct.inc
  TP_PControl := RegisterUserType('PControl');[/code]
в качестве результата возвращается data_object + offset

объявление переменной пользовательского типа в среде:
lang(frm:PControl)[/code]

проверка типа перенной на соответствие данному типу:
    if(expof(cnt) != PControl)
      error('В качестве Control указан не верный тип данных')
end

[size=-2]------ Добавлено в 16:36 [/size]
полагаю для FTCG пакетов имеет смысл сделать возможность подцветки ошибочных линков прямо в среде после компиляции.
карма: 27
0
Разработчик
Ответов: 26170
Рейтинг: 2127
#60: 2007-06-29 16:39:20 ЛС | профиль | цитата
Dilma писал(а):
возможность подцветки ошибочных линков прямо в среде после компиляции

Хорошая мысль.
карма: 22

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)