Forth - язык нового поколения :)

 
1 2 3 4
+
-
edit
 

zespri

новичок
Balancer>Получаем переносимую на уровне кода систему (а в случае C# - так и на уровне конечного бинарника) для реализации которой не требуется даже знать, как устроены бинарники на нужной платформе :)[»]

А вот в каноническом форте какэто всё работает? Я имею в виду шитый код. Ведь в конечном итоге интерпретатор интерпретирующий шитый код вызывает машинные подпрограммы. Вопрос такой, откуда эти подпрограммы берутся? Я так себе представляю только два пути. Во-первых подпрограммы реализованые ядром, во-вторых подпрограммы которые ты скомпилировал сам с помощью форт-ассемблера (ну или прямой записью машинных инструкций в память, но это для извращенцев). Если ты в ручную не генерируешь машинный код, то всё что генерирует компилятор это только шитый код, и дополнительному машинному коду там взяться неоткуда. Я прав?
 
+
-
edit
 

Balancer

администратор
★★★★★
zespri>Если ты в ручную не генерируешь машинный код, то всё что генерирует компилятор это только шитый код, и дополнительному машинному коду там взяться неоткуда. Я прав?

Шитый код бывает двух видов - прямой, когда в коде прямо указываются адреса подпрограмм в машинных кодах или адреса ячеек с этими адресами (когда идёт экономия на прологе комиплированных Форт-слов), и косвенный, когда в коде слов указываются не сами эти адреса, а адреса или индексы ячеек, где они хранятся.

Т.о., если обеспечить фиксированные индексы слов ядра, то Форт-расширение становится переносимым.
 
+
-
edit
 

zespri

новичок
Balancer>Шитый код бывает двух видов - прямой, когда в коде прямо указываются адреса подпрограмм в машинных кодах или адреса ячеек с этими адресами (когда идёт экономия на прологе комиплированных Форт-слов), и косвенный, когда в коде слов указываются не сами эти адреса, а адреса или индексы ячеек, где они хранятся.

Об этом я в курсе =)

Balancer>Т.о., если обеспечить фиксированные индексы слов ядра, то Форт-расширение становится переносимым.[»]

И до этого тоже догадался уже, потребовалось минут 10 =) Ты вобщем то ответил мне на тот вопрос, который я стёр, потому что сам сообразил, а не на тот, который я таки задал =) Повторю вопрос, верно ли что ":" и "DOES>" генрерируют исключительно шитый код и никакого машинного (речь идёт о косвенном шитом коде)?
 
+
-
edit
 

zespri

новичок
Кирилл>Реализация занимает меньше места, чем этот текст.

Да, спасибо, хотя я и не знаком со SmallTalk, идея вполне проста и понятна. Разумеется только после того как ты её объяснил =) Ничего, кстати, что я "на ты"? Я начинал с фидо, и моя "сетевая этика" оттуда.


 
+
-
edit
 

Balancer

администратор
★★★★★
zespri>Повторю вопрос, верно ли что ":" и "DOES>" генрерируют исключительно шитый код и никакого машинного (речь идёт о косвенном шитом коде)?

Ну да, естественно!
Как говорится, всю жизнь так было, до появления SPF4 :)
 
RU Кирилл #02.09.2004 14:45
+
-
edit
 

Кирилл

втянувшийся

2 Balancer
> Ну да, естественно! Как говорится, всю жизнь так было, до появления SPF4
Это не совсем так (придирка :) ). Слово высокого уровня совсем не содержит машинный код только для косвенного шитого кода. На писюках же обычно используется прямой шитый код, и там машинный код обязательно присутствует в cfa (поле кода).
2 zespri
> Да, спасибо, хотя я и не знаком со SmallTalk, идея вполне проста и понятна. Разумеется только после того как ты её объяснил =) Ничего, кстати, что я "на ты"? Я начинал с фидо, и моя "сетевая этика" оттуда.
Ничего страшного. Я обычно перехожу на "ты" после нескольких постов в дружеской дискуссии, как сейчас :)
А идеи можно было позаимствовать и у Страустрапа, и у разработчиков VC++ - если на традиционных языках реализация "чуждых" им моделей будет крайне неуклюжей (например, другой ООП для Си), то для Форта расширение за счет "чужих" идей и понятий совершенно естественно. Например, когда мне понадобился опертор WITN (а в Си его нету :( ) для работы со структурами и классами - я его сделал сам, причем я отнюдь не матерый фортер. Кстати, ты книгу Броуди Thinking Forth читал?
- Сами понимаете, вселенная-то на моей стороне.
- Вот это мне таким вульгарным и кажется.
 
+
-
edit
 

Balancer

администратор
★★★★★
Кирилл>Это не совсем так (придирка :) ). Слово высокого уровня совсем не содержит машинный код только для косвенного шитого кода. На писюках же обычно используется прямой шитый код, и там машинный код обязательно присутствует в cfa (поле кода).

Фиг там! Это уже издержки x86-архитектуры с целью оптимизации :D
CFA = CODE FIELD ADRESS. Т.е. ячейка, где записан адрес кода. В классическом прямом шитом коде в поле CFA каждого слова записан адрес кода, его выполняющего. Для переменной это будет код, который направит в стек адрес следующей ячейки, для CODE-блока - адрес, буквально идущий следом, для Форт-слова - адрес кода интерпретатора шитого кода, идущего следом.

Но на PC уже давно с целью оптимизации решили заменить CFA сразу на CODE-блок, выполняющий нужное действие, так что смысл CFA вообще теряется.

Косвенный же шитый код отличается от прямого тем, что в CFA хранятся не адреса кода, а адреса ячеек, где хранятся адреса кода. Т.о. подменой одной ячейки можно добиться вызова другого слова по всей Форт-программе. В прямом шитом коде с этим сложнее :)

Кирилл>Кстати, ты книгу Броуди Thinking Forth читал?

Кстати, мне довелось поработать вместе с её переводчиком, Сергеем Дмитренко. Как раз и на Форте тогда "коммерчески" попрограмимровал :)
 
+
-
edit
 

zespri

новичок
Balancer>Как говорится, всю жизнь так было, до появления SPF4 :)[»]

И что нового нам привнёс spf4?
 
+
-
edit
 

Balancer

администратор
★★★★★
zespri>И что нового нам привнёс spf4?[»]

Первый популярный Forth, генерирующий машинный код :)
 
NZ zespri #02.09.2004 15:39  @Кирилл#02.09.2004 14:45
+
-
edit
 

zespri

новичок
Кирилл>Кстати, ты книгу Броуди Thinking Forth читал?[»]

Я читал её 15 лет назад целиком, и последний год просматривал несколько отрывков что бы отвежить память.
 

zespri

новичок
zespri>>И что нового нам привнёс spf4?[»]
Balancer>Первый популярный Forth, генерирующий машинный код :)[»]

Ага! Глядя на него последние две недели я уж было грешным делом решил, что в фортовом мире генерация машинного кода, практически стандарт =)

Ладно, понемногу фортовская сторона проблемы в голве устаканивается, понадобится ещ несколько итераций, но после. Сегодня думал о дотнетной части. С ней вот какая проблема. Динамическая генерация кода возможна только на уровне класса. Причем в сгенерённый класс уже новых методов не добавить. Хотя существующие изменить можно. (Странно) Я представлял себе что мы будем использовать дотнетный класс как своего рода словарь для не oop слов. Так вот не выходит. Получается что на каждое слово придётся генерить по классу, иначе никак. Перегенерировать класс заново, когда добваляется новое слово катастрофически медленно и жрет много лищнего места. Так что я сейчас пытаюсь провентилировать этот вопрос в clr-ных комьюнитях, о результатах доложу.
 
RU Кирилл #02.09.2004 20:50
+
-
edit
 

Кирилл

втянувшийся

2 zespi
Тогда лучше все-таки использовать косвенный шитый код - его-то можно оформить как данные, а в объект упаковывать только code-слова ядра. Производительность упадет, но .net вроде на супер производительность и не рассчитано. Заодно появятся такие фичм как декомпилятор, пошаговая отладка и т.п.
- Сами понимаете, вселенная-то на моей стороне.
- Вот это мне таким вульгарным и кажется.
 
Это сообщение редактировалось 03.09.2004 в 11:21
+
-
edit
 

Balancer

администратор
★★★★★
Кирилл>Производительность упадет, но .dot вроде на супер производительность и не рассчитано.

Ну, надо отметить, что C# очень мало уступает под Win32 нативному C++ даже на чисто вычислительных задачах.

Кирилл>Заодно появятся такие фичм как декомпилятор, пошаговая отладка и т.п.

Да там много чего появляется... Кстати, слово SEE, которое по сути было декомпилятором, было чуть ли не стандартным в своё время.



Прикреплённые файлы:
 
 
+
-
edit
 

zespri

новичок
В следующей версии дот нета (2.0) появится возможность динамически добавлять методы в существующий класс. Будем ждать нового года =)

 
+
-
edit
 

zespri

новичок
Следующий вопрос. А как господа относят к идее "фиксированного числа аргументов"? Если делать строгую типизацию, то и эта идея на фоне строгой типизации на мой взгляд смотрится не хуже. Идея не в том, что нельзя создать слово, которое может обрабатывать переменное число аргументов со стека, а в том, что перед вызовом любого слова программист обязан специфицировать сколько аргументов на стеке предназанчено для этого слова. Система выдаст ошибку, если слово попытается снять со стека больше аргументов.

Что плохого вы видите в этой идее?
 
+
-
edit
 

Balancer

администратор
★★★★★
zespri>Что плохого вы видите в этой идее?[»]

Слово может снимать разное число аргументов. В первую очередь по побочным эффектам, конечно, типа глобальных переменных, но, ИМХО, лишать Форт такой возможности - над этим надо сильно думать :)
 

zespri

новичок
zespri>>Что плохого вы видите в этой идее?[»]
Balancer>Слово может снимать разное число аргументов. В первую очередь по побочным эффектам, конечно, типа глобальных переменных, но, ИМХО, лишать Форт такой возможности - над этим надо сильно думать :)[»]

Я предлагаю оставить возможность слову снимать произвольное количество элементов, я лишь хочу зафикчировать количество аргументов при данном конкретном запуске этого слова.

Откуда ноги растут. Идеи c rtti типами и переключением словарей, конечно здоровские идеи для канонического форта. Но если мы пишем фортоподобный язык под дот нет я бы хотел видеть у него следующие свойства:

1) Возможность без извратов пользоваться любыми уже созданными дотнетными классами
2) Возможность создавать классы которыми без извратов смогут пользоваться другие дотнетные классы

Точно так же как форт накладывает ограничения на реализацию, точно так же и дот нет накладывает свои ограничения. То есть без выполнения 1) и 2) и начинать смысла не имеет.

Далее. Для того что бы вызвать любой дотнетный метод необходимо знать его сигнатуру. Без этого никак. Следовательно надо знать число его параметров. Поэтому когода выполняется слово, то количество его параметров должно быть заранее известно. Я в данном случае представляю, что слова будут реализоваться как дотнетые методы, а не как шитый код. Почему? Всё потому же, я хочу получить язык который может interoperate с другими языками дотнетной платформы, и я хочу избежать написания artificial кода единственным назначением которого является мэпить совершенно не ложащиеся в структкру дотнета фичи языка. Я хочу что бы язык ложился на .net стольже органично как скажем C# и VB.

Я представляю себе это так. На стеке живут не числа а объекты в смысле дот нета. Словарь представляет собой класс со статическими методами. Соотвественно для выполнения слов из текущего словаря не необходимости задавать объект класса, достаточно просто метода и параметров. Для того что бы положить на стек класс необходимо его инициализировать. Для этого будет предназначено слово из стандартного словаря которое будет снимать со стека параметры для конструктора и класть на стек готовый объект. Таким же образом можно будет вызывать методы на верхнем объекте стека, описывать новые объекты состоящие из полей и методов, а так же добавлять статические методы-слова в классы словари.

Это грубая идея. Но это всё не будет работать без того что бы при вызове любого слова не знать на перёд количество его параметров.
 
+
-
edit
 

Balancer

администратор
★★★★★
zespri>Я предлагаю оставить возможность слову снимать произвольное количество элементов, я лишь хочу зафикчировать количество аргументов при данном конкретном запуске этого слова.

Я так понимаю, что это число должно быть определено до запуска? Как этого добиться?

zespri>Далее. Для того что бы вызвать любой дотнетный метод необходимо знать его сигнатуру. Без этого никак. Следовательно надо знать число его параметров.

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

zespri>Я представляю себе это так. На стеке живут не числа а объекты в смысле дот нета.

Согласен.
 
RU Кирилл #04.09.2004 11:07
+
-
edit
 

Кирилл

втянувшийся

2 zespri
Итак, основные требования определены
> 1) Возможность без извратов пользоваться любыми уже созданными дотнетными классами
> 2) Возможность создавать классы которыми без извратов смогут пользоваться другие дотнетные классы
Но вот предлагаемая реализация ИМХО нехороша
> Далее. Для того что бы вызвать любой дотнетный метод необходимо знать его сигнатуру. Без этого никак. Следовательно надо знать число его параметров. Поэтому когода выполняется слово, то количество его параметров должно быть заранее известно. Я в данном случае представляю, что слова будут реализоваться как дотнетые методы, а не как шитый код. Почему? Всё потому же, я хочу получить язык который может interoperate с другими языками дотнетной платформы, и я хочу избежать написания artificial кода единственным назначением которого является мэпить совершенно не ложащиеся в структкру дотнета фичи языка. Я хочу что бы язык ложился на .net стольже органично как скажем C# и VB.
Реализация слов как .NET методов убивает одно из важнейших преимуществ Форта - дешевизну вызовов. А если учесть очень маленькие размеры слов, то результатом станет совершенно неприемлемое падение производительности.
Вернемя к поставленной задаче. Не нужно делать ВСЕ слова доступными "чужим". Надо только возможность юзать "чужие" классы + возможность создавать совместимые свои. Такие вещи спокойно реализуются на Форте, а за код, конвертирующий вызов метода в вызов слова, бояться не надо - он примерно равен по объему обычным прологу и эпилогу подпрограммы. Посмотри, например, как в SPF сделан доступ к WINAPI и объектам COM.
- Сами понимаете, вселенная-то на моей стороне.
- Вот это мне таким вульгарным и кажется.
 
+
-
edit
 

zespri

новичок
Кирилл>Реализация слов как .NET методов убивает одно из важнейших преимуществ Форта - дешевизну вызовов.

Balancer, можно узнать твоё мнение, согласен ли ты что дешевизна вызовов - это одно из важнейших перимуществ форта?
 
+
-
edit
 

zespri

новичок
Кирилл>Реализация слов как .NET методов убивает одно из важнейших преимуществ Форта - дешевизну вызовов.

Кирилл, почему из-за реализации слов как .net методов вызовы становятся дороже?
 
+
-
edit
 

Balancer

администратор
★★★★★
zespri>Balancer, можно узнать твоё мнение, согласен ли ты что дешевизна вызовов - это одно из важнейших перимуществ форта?

Это не то, чтобы явное преимущество, у многих современных ЯВУ вызовы бывают дешевле. Но Форт-стиль программирования требует дешёвых вызовов. Так что если чистые .NET-методы будут накладны, то надо делать их уже в виде расширения обычных, а не методами по умолчанию.
 
RU Кирилл #04.09.2004 12:41
+
-
edit
 

Кирилл

втянувшийся

2 zespri
> Кирилл, почему из-за реализации слов как .net методов вызовы становятся дороже?
Форт-слову не надо подготавливать к передаче параметры, Форт-слово может возвращать несколько значений, вызов Форт-слова любой сложности (и с любыми параметрами) - один адрес (одна ячейка) или одна команда call или один элемент байт-кода. Если при оформлении слова как .NET-метода удастся это обеспечить без дополнительных накладных расходов, то все хорошо, иначе мой тезис :) остается в силе.
- Сами понимаете, вселенная-то на моей стороне.
- Вот это мне таким вульгарным и кажется.
 
+
-
edit
 

zespri

новичок
>> Кирилл, почему из-за реализации слов как .net методов вызовы становятся дороже?
Кирилл>Форт-слову не надо подготавливать к передаче параметры, Форт-слово может возвращать несколько значений, вызов Форт-слова любой сложности (и с любыми параметрами) - один адрес (одна ячейка) или одна команда call или один элемент байт-кода. Если при оформлении слова как .NET-метода удастся это обеспечить без дополнительных накладных расходов, то все хорошо, иначе мой тезис :) остается в силе.

При компиляции удастся, при интерпретации нет.
 
RU Кирилл #28.09.2004 21:40
+
-
edit
 

Кирилл

втянувшийся

2 zespri
С возвращением на форум!
Можно у тебя побольше узнать о потрохах виртуальной .NET-машины (в английском я не силен)?
Есть идея по типизации в Форте: введи типизированные локальные переменные; если это будут классы, то можно будет проверить тип данных на лету.
- Сами понимаете, вселенная-то на моей стороне.
- Вот это мне таким вульгарным и кажется.
 
1 2 3 4

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru