Модераторы: Hawk, Romeo, Absurd, DeeJayC, WinMain
Код: Выделить всё
#include <System/Main.h>
Int boot()
{
RunCPPFile("System/kernel.cpp");
if error=1
{
RunCPPFile("Recovery/booterr.cpp");
return 0
}
return 1
}
Что бы человек не подумал, обязательно найдется хотя бы один человек, который думал точно так же.Почему до меня этого никто не выдумал?
Было. ZX-SPECTRUM.SuperProgrammer писал(а):Я хочу зашить в микросхему интерпретатор языка,
Интерпретаторы работают медленнее натива. Есть ровно три случая, когда интерпретация оправдана:SuperProgrammer писал(а):Которой будет грузить ОС написанную на С++ например. В корне диска будет лежать что-то вроде BOOT.BDF в котором будет находится начальный код для интерпретации.
Код: Выделить всё
ADD AX, WORD PTR[x]Код: Выделить всё
MOV BX, WORD PTR[x]
ADD AX, BXZ80 вполне справлялся с "драйверами" джойстиков, писанными прямо на бейсике.somewhere писал(а):Что бы человек не подумал, обязательно найдется хотя бы один человек, который думал точно так же.
Это плохая идея хотя бы по одной причине - загрузка будет происходить очень медленно. Хотя это, конечно, зависит от того, что вы понимаете под операционной системой. Стесняюсь спросить, драйверы устройств вы тоже хотите через интерпретатор реализовать? А сам интерпретатор, зашитый в микросхему, стало быть написан на асме? - у вас должна быть очень производительная "микросхема" в данном случае =)
Громко сказано. Там весь "драйвер" сводился к чтению установленых битов из порта. А для Sinclair-джойстика это были тупо цифровые клавиши и достаточно было опрашивать состояние клавиш.Z80 вполне справлялся с "драйверами" джойстиков, писанными прямо на бейсике.
На спектруме все таки была прекомпиляция. В памяти не хранился полный текст команд, а только их коды. Для операндов были их вычисленные значения. Примерно с адреса 21700 начинались все программы на бейсике.Было. ZX-SPECTRUM.
Давайте вспомним, что тема у нас про ОС через интерпретатор. А вы сравниваете бумажный самолетик и Боинг 747А в микросхемы принтеров зашивают интерпретаторы PostScript.
Код: Выделить всё
10 INPUT "y=";f$, "xmin=";xmin; "xmax=";xmax, "Step=";s
20 FOR x=xmin TO xmax STEP s
30 LET y=val(f$)
40 PLOT x*10+128,y*10+96
50 NEXT xА теперь вопрос: почему слово "драйвер" уже в моём посте было взято в кавычки?somewhere писал(а):Громко сказано. Там весь "драйвер" сводился к чтению установленых битов из порта.
Прекодирование, ИМХО так будет правильней, так как результат даже близко не валялся с нативом, имел тот же уровень абстракции, что и исходный текст, и исходным текстом всегда был густо нафарширован.somewhere писал(а):На спектруме все таки была прекомпиляция. В памяти не хранился полный текст команд, а только их коды.
ОС тоже бывают разные, некоторые вполне профессиональные ОС отлично встают даже на контроллеры, управляющие станками. А принтер - что такое, если не печатный станок?Давайте вспомним, что тема у нас про ОС через интерпретатор. А вы сравниваете бумажный самолетик и Боинг 747
Пусть процессор имеет быстродействие один миллион операций в секунду, программа не может содержать ни явных циклов, ни переходов назад и состоит из не более, чем 20-ти операторов, а исполняется со скоростью 300 операторов в секунду. Тогда пользователь не заметит разницы между интерпретацией с такой скоростью и исполнением натива. Да и 20 операторов в секунду при тех же ограничениях могут быть приемлемы, но уже заметны. Если же программа одноразовая, то время исполнения надо в любом случае складывать со временем трансляции, не зависимо от того, компилируется она или интерпретируется. Но интерпретатор потому и тормозит, что транслирует прямо во время исполнения, полное время исполнения с точки зрения пользователя - это и есть та самая сумма. А в сумме со временем компиляции при таких ограничениях ИМХО будет даже медленее. Циклические программы интерпретируются всё равно медленнее из-за того, что каждый оператор тела цикла интерпретируется на каждом шагу, а компилируется лишь однажды. Но при отсутствии циклов как явных, так и построенных на переходах этого фактора не будет. Если программа должна вывести много текста в текстовом диалоге с пользователем, то сразу и факторы длины и цикличности программы теряют значение, так как даже при скорости 2 оператора в секунду лимитировать будет скорость чтения человеком. Графика является более емким представлением, которое человек может воспринимать очень быстро, так что тогда даже натив на процессоре с миллионом операций в секунду может и отставать от скорости восприятия пользователем, особенно при избыточном качестве картинки. А если скорость исполнения лимитируется механической частью? Например, графический язык, интерпретируемый чипом графопостроителя и на нём программа вывода страницы этим графопостроителем и возьмём с потолка, что графопостроитель способен вывести не более 4-х штрихов в секунду. Тогда не имеет значения, может ли электронная часть графопостроителя исполнить за секунду 4 триллиона штрихов, или только 4 штриха, устройство целиком всё равно будет исполнять только 4 штриха в секунду и к тому же процессор вынужден будет работать также медленно. При этом посылать отдельные сигналы в реалтайме и принимать их в реалтайме с датчиков интерпретация ему ни как не помешает, за это отвечает код интерпретатора, а не страницы, а он то в нативе. Всё зависит от назначения и от того, на сколько ограничена сама программа и данные, с которыми она может работать. Если найти нишу, в которой интерпретация гарантирует приемлемую скорость исполнения, а закрывать исходники программ не требуется и достаточно простой язык, чтоб во-первых не интерпретировался ещё медленнее, а во-вторых чтоб сам интерпретатор был мал и не требовал для своего размещения дорогих ПЗУ большого объёма, тогда можно шить интепретатор в ПЗУ. Но при этом назначение языка должно соответствовать назначению устройства, нельзя шить LOGO в калькулятор и форт в принтер. Форт, кстати, отличается тем, что даже его компиляторы часто шили в чипы встраиваемой техники. Но не во всю подряд.somewhere писал(а):Если интерпретатор будет еще и текст парсить, то результат работы будет еще медленнее.