ПО, ЭВМ и АСУ из Таможенного Союза

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » ПО, ЭВМ и АСУ из Таможенного Союза » Проект "Виртуальные машины" » Первая реализация. Исходники.


Первая реализация. Исходники.

Сообщений 31 страница 60 из 62

1

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

main.r
Код:
 
#вставка    "library.h" 
#вставка 	<locale.h> 	//Во избежание "крокозяблей" на выводе
#вставка 	<stdio.h> 	//Стандартный однобайтовый ввод-вывод
#вставка 	<wchar.h> 	//"Широкие" многобайтовые символы и их ввод-вывод
#вставка 	<wctype.h> 	//"Классификация" широких символов

#вставка	"vm.h"    //Внешний интерфейс виртуальной машины

// при подключении файлов из других папок будьте внимательны с путями,
// так как перед компиляцией С/С++ файлы будут находится в папке .src/
 
цел main()
{
    //включение всех локалей
	setlocale(LC_ALL, "");
	system("cls");
	пчтф16(L"Новый проект.\n");
	
	//в переменной типа ТВМ "упакована" все внутреннее устройство ВМ:
	// регистры, стек, память указатели и тд. 
	ТВМ* ВМ1 = создать_ВМ();
	
	// программа состоящая их одной тестовой инструкции. 
	б64 программа = 16"FFFF;
	//Тут требуется подумать. Программа загружается как массив байтов. 
	загрузить_ВМ(ВМ1,(симв*) &программа, (симв*)((&программа)+1));
	//Наверное, имеет смысл совсместить загрузку и старт программы в одной инструкции.
	старт_ВМ(ВМ1);
	// освобождаем динамически выделенную память под ВМ.
	закрыть_ВМ (ВМ1);
	читз();
	вернуть 0;  
}	

В следующих двух файлах описана интерфейсная часть ВМ. То есть, какие функции доступны нам для использования ВМ.

vm.rh vm.r
Код:
#если_нет 	VM_H
#макрос	  	VM_H	
//===========================================================
// 	Файл:    vm.rh
// 	Версия:    1.00
// 	Дата:    17.06.2022
//	Описание:	Описание внешнего интерфейса виртуальной машины (ВМ)
//        доступ к внутренним структурам ВМ извне напрямую запрещен
//	Автор:
//===========================================================

тип структура ТВМ ТВМ;
 
// Внешний интерфейс управления виртуальной машиной
ТВМ* создать_ВМ();        // конструктор
пуст закрыть_ВМ(ТВМ* эта_ВМ);	// деструктор
пуст загрузить_ВМ(ТВМ* эта_ВМ, симв * старт_адрес, симв* стоп_адрес);	// загрузка программы в байт-кодах в ВМ
пуст старт_ВМ(ТВМ* эта_ВМ);    // запуск работы ВМ

 

#к_если    //VM_H

Код:
//===========================================================
// 	Файл:    vm.r
// 	Версия:    1.00
// 	Дата:    17.06.2022
//	Описание:	Реализация интерфейса виртуальной машины (ВМ)
//        доступ к внутренним структурам ВМ извне напрямую запрещен
//	Автор:
//===========================================================
#вставка    "library.h" 
#вставка	"vm.h"
#вставка	"vm_core.h"

// Конструктор виртуальной машины
ТВМ* создать_ВМ()
{
	ТВМ* врем = (ТВМ*) malloc (sizeof(ТВМ));
	/****начало тестового блока****/
	врем->имя[0] = 'V';
	врем->имя[1] = 'M';
	врем->имя[2] = '1';
	врем->имя[3] = '\n';
	врем->имя[4] = '\0';
	/****конец тестового блока****/
	вернуть врем;
}
// Деструктор виртуальной машины
пуст закрыть_ВМ(ТВМ* эта_ВМ)
{
	free(эта_ВМ);
}
// загрузка программы в байт-кодах в ВМ
пуст загрузить_ВМ(ТВМ* эта_ВМ, симв * старт_адрес, симв* стоп_адрес)
{
	эта_ВМ->РЕГИСТР_А = *((б64*) старт_адрес);
}	

//Запуск виртуальной машины
пуст старт_ВМ(ТВМ* эта_ВМ)
{
	/****начало тестового блока****/
	пчтф(эта_ВМ->имя);
	если (эта_ВМ->РЕГИСТР_А == 16"FFFF){
    пчтф16(L"Выполнена тестовая инструкция!\n");
	}
	/****конец тестового блока****/
}

А теперь начало реализации самой ВМ.

vm_core.rh
Код:
#если_нет 	VM_CORE_H
#макрос	  	VM_CORE_H	
//===========================================================
// 	Файл:    vm_core.rh
// 	Версия:    1.00
// 	Дата:    17.06.2022
//	Описание:	Описание внутреннего устройства виртуальной машины (ВМ)
//	Автор:
//===========================================================
#макрос РЕГИСТР_А регистры[0]
#макрос РЕГИСТР_Б регистры[1]
#макрос РЕГИСТР_В регистры[2]
#макрос РЕГИСТР_Г регистры[3]
#макрос РЕГИСТР_Д регистры[4]
#макрос РЕГИСТР_Е регистры[5]
#макрос РЕГИСТР_Ж регистры[6]
#макрос РЕГИСТР_З регистры[7]
#макрос РЕГИСТР_И регистры[8]
#макрос РЕГИСТР_К регистры[9]
#макрос РЕГИСТР_Л регистры[10]
#макрос РЕГИСТР_М регистры[11]
#макрос РЕГИСТР_Н регистры[12]
#макрос РЕГИСТР_О регистры[13]
#макрос РЕГИСТР_П регистры[14]
#макрос РЕГИСТР_Р регистры[15]

// Структура,описывающая виртуальную машину
структура ТВМ {
 	симв имя[10];
 	б64 регистры[16];
 	
 };

#к_если    //VM_CORE_H

0

31

БудДен написал(а):

Тут весь вопрос в том, что дел много (выбор проектов огромен), любителей программирования на русском языке немного, каждый из них хочет быть главным и зачастую имеет свой любимый проект, которому и посвящает свободные силы. Например, на этом форуме почти у всех такой проект есть. Вероятность, что оттенки вкусовых пристрастий совпадут - минимальны. Можешь попробовать начать с того, что выяснить, у кого какие проекты уже есть и присоединиться к существующему, т.е. уступить во вкусовых пристрастиях.


Я собственно и поддержал, и присоединился к проекту виртуальной машины, идейным вдохновителем которой был Лис. Я отнюдь не стремлюсь быть главным - меня устраивает вариант сотрудничества на принципах взаимного уважения и доверия. Честно говоря, эмоциональный выплеск Лиса меня напряг. Тем не менее я готов продолжать проект ВМ, если моя компания Лиса устраивает. Когда Лис свою позицию обозначит, тогда и будем решать, что делать дальше. Любые технические моменты решаемы, а вот психологические не всегда...

0

32

> Я собственно и поддержал, и присоединился к проекту виртуальной машины, идейным вдохновителем которой был Лис.

Видимо, я что-то пропустил. Думал, это твой проект.

0

33

Евгений написал(а):

Честно говоря, эмоциональный выплеск Лиса меня напряг.

Это после неудачной вылазки в Америке. Понять и побить.

0

34

Евгений написал(а):

эмоциональный выплеск Лиса меня напряг.

Хотелось бы подробностей - чем именно.

С точки зрения публичного проекта лицензионная чистота - это важно по мнению Лиса, он просто об этом сказал.

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

Евгений написал(а):

я готов продолжать проект ВМ, если моя компания Лиса устраивает.

Вы писали

Евгений написал(а):

Суммарный потенциал нескольких человек, объединенных общим делом, всегда выше чем, потенциал тех же людей, работающих индивидуально.

("порядок бьёт класс" и всё такое).
Как это выглядит на практике? Это значит, что организуются несколько штук проектов для достижения целей и обеспечивается взаимодействие между ними.

Лиса устраивает твоя компания. Если ты доделаешь ВМ, останется результат. Потом придёт кто-то ещё, сделает поверх язык. Нужно просто больше людей.

Конечно, Лис бы хотел, чтобы вместо русификатора от Юрия использовался компилятор от Павиа.
Дело тут не в личном отношении к Юрию и к Павиа, а в меньшем количестве зависимостей от иностранных технологий.
Но Лис понимает, что переубедить кого-либо в чём-либо невозможно. Поэтому Лис морально поддерживает и одобряет активность в том виде, в каком она есть.

Отредактировано Лис (2022-06-21 19:27:26)

0

35

Лис написал(а):

Хотелось бы подробностей - чем именно.

Пусть это останется отдельным случайным эпизодом, мне совсем не хочется начинать дискуссию в этом направлении.

Лис написал(а):

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

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

Лис написал(а):

Это значит, что организуются несколько штук проектов для достижения целей и обеспечивается взаимодействие между ними.

У нас нет возможности запустить несколько параллельных проектов, просто нет достаточного количества участников. Давайте для начала попробуем осуществить обсуждение идей и их реализацию в рамках одного проекта.

0

36

Заготовку исходников положил на твойгит.
Какой следующий шаг?
1. Мне видится, что нужно хотя бы приблизительно описать структуру файла с байт-кодом.
2. Потом нужно договориться об адресации в командах байт-кода.
3. А дальше начать прорисовывать более конкретную структуру ВМ.

0

37

Евгений написал(а):

нужно хотя бы приблизительно описать структуру файла с байт-кодом

Ну наверное это зависит от требований.

Нужно ли будет поддерживать несколько разных архитектур, либо несколько разных версий одного набора инструкций? (этим занимается PE-заголовок)
Кто и как будет размещать код в памяти? (BigEndian/Little Endian, разделение на сегменты, располагаемые с разрывами в адресном пространстве, выбор формата заполнения стартового стека, как предоставляется таблица системных вызовов)
Будут ли существовать динамически загружаемые библиотеки? (Загрузке помогают таблицы экспортированных символов)
Какие соглашения по вызовам и наименования функций? (__fastcall/__stdcall, __cdecl)
Нужно ли будет размещать библиотеки при загрузке по разным адресам, для рандомизации, или учёта разных "аппаратных" конфигураций? (этим занимаются таблицы релокации)
Как хранится отладочная информация? (разные форматы)
Как хранится связь с исходными текстами, и сами исходные тексты? (АПИ сервера символов или директория в FHS)
Добавляется ли телеметрия для построчного/посимвольного авторства, лицензий и биллинга? (нигде нет, моя мечта)
Как записываются версии бинарников и как хранятся описания зависимостей (есть в манифестах .Net сборок, а так же в линуксовых пакетных менеджерах)
Есть ли контрольные суммы (checksums), цифровые отпечатки (fingerprint), цифровые подписи (code signing)? (Есть в старых .net-ассемблях)

Так-то самый простой формат - инструкции хранятся последовательно, начиная с фиксированного адреса и больше ничего нет (.com-файл из freedos, и то там есть program segment prefix).
Да и то, в файлах ZX Spectrum, на магнитной ленте, был заголовок и тело файла, а сами байты грузились отдельно в видеопамять, отдельно в RAM (но могли и совмещать).

Описать это всё русскими буквами - это значит создать документ-спецификацию. И нужен комитет по стандартизации (или хотя бы репозиторий), который будет такие документы хранить.

Ранее по теме:
байткод КуМир-а

Отредактировано Лис (2023-02-19 20:53:16)

0

38

Евгений написал(а):

нужно договориться об адресации в командах байт-кода.

Тут не ясно, что имеется в виду. Есть два возможных значения.
1) имеется в виду архитектура процессора, адресация это как устроен доступ к памяти в многопроцессорной системе, может там NUMA
2) имеется в виду, как кодируется структура инструкции. Сначала опкод, затем описание операндов, либо несколько опкодов в слове фиксированной длины

группируются ли, кстати, команды не в рамках одного машинного слова, а в рамках процессорного кеша, как предлагала, но не реализовала Microsoft?

0

39

Евгений написал(а):

прорисовывать более конкретную структуру ВМ.

Тут тоже непонятно, что имеется в виду.
1) возможно это то, что прописывается при конфигурировании виртуальной машины в Qemu - сколько видеоадаптеров и где их память, какие устройства подключены через USB, через SATA и т.д.
2) возможно что имеется архитектура материнской платы. Существуют же сетевые сортировщики, систолические структуры и тому подобные кошмары
3) возможно что архитектура процессора - количество операндов, разные варианты связок между инструкциями (в теории компиляции и, кажется, в llvm, код представляют "четвёрками" или ещё как-нибудь так абстрактно)

Отредактировано Лис (2023-02-19 17:56:10)

0

40

Самое главное - на какое железо будет сажаться предлагаемый набор стандартов.

Варианты приземлений: Эльбрус, Арм64 (Байкал), Интел64, РискВ64
Возможно что надо прямо сразу четыре варианта делать и поверх слой абстракции (в проекте Qemu с этим же справляется один человек?)

Или как у немцев/германцев идти на уровень ниже, уровень логики, делать универсальный язык описания процессорных архитектур.

В общем, надо много, много писать (до линьки осталось 111 сообщений). И не точно, что код программной реализации (потому что читать код не будут из принципа).
И что характерно, на английском языке - пишут. Большое количество текстов на разные темы. И собирают, и упорядочивают. Хорошо иметь миллиард англоговорящего населения и большое количество студентов... Плохо иметь 100 миллионов демотивированного населения. Ещё хуже языкам малых народов, на которых говорят только в нескольких поселениях.

Отредактировано Лис (2023-02-19 18:10:24)

0

41

Лис написал(а):

Описать это всё русскими буквами - это значит создать документ-спецификацию. И нужен комитет по стандартизации (или хотя бы репозиторий), который будет такие документы хранить.

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

На мой взгляд нужен эволюционный процесс: от простого к сложному. С документированием пройденного пути.

Лис написал(а):

И что характерно, на английском языке - пишут.

Тут предельно просто. Прежде чем что-то написать, эти люди имеют возможность что-то прочитать. И читают они не на русском и не на китайском.

Лис написал(а):

По-хорошему, надо написать:
1) отдельную новую виртуальную машину (я тут уже писал, про машину Поста)
2) язык программирования поверх неё
3) графическую библиотеку и библиотеку ввода-вывода
4) ИДЕ (если так хочется), поверх тех библиотек и языка
5) даже без ИДЕ можно писать web-сервер для движка сайта под нужды сообщества (и это будет проще, чем работа с графикой)

Лис написал(а):

Я бы ещё обратил внимание, что надо разделить спецификацию на две:
- описание самой машины
- описание бинарного формата загружаемого файла

Эти задачи мне по крайней мере понятны в целом, детально же можно прорабатывать. Предлагаю на них для начала и сосредоточиться.
Стартовая платформа (на которой и для которой разрабатывается ВМ) - Интел64, ОС - Линукс.

0

42

Разбирался с оформлением файла readme.md на твойгит. Результат можно посмотреть все там же на твойгит
Так же разбирался с возможностью генерации документации для кода с помощью Doxygen. Первые результаты обнадеживают.

0

43

Добавил три арифметические команды. Обновил исходники. Но пока мне не очень нравится...
Основные изменения в vm.r

Отредактировано Евгений (2023-03-10 01:36:00)

0

44

Евгений написал(а):

Добавил три арифметические команды.

Я тоже хочу добавить какую-нибудь команду. Из виртуальной машины КуМир хочу команду
СУММ (у них было SUM) с кодом операции 0xF1
Что мне надо написать?

Отредактировано Лис (2023-03-10 05:52:52)

0

45

Я не знаю. Это идея Лиса. С какой стороны к ней подходить мне не понятно даже приблизительно.

0

46

Евгений написал(а):

Я не знаю. Это идея Лиса. С какой стороны к ней подходить мне не понятно даже приблизительно.

Надо рассмотреть опыт акул капитализма. В данном случае - эмулятора QEMU.

Когда запускается команда qemu, ей передаётся большое количество параметров командной строки.
Один из этих параметров - описание машины, а второй - тип процессора (второй пока не нужен).

Я думаю, что когда запускается Сказочная Колесница,
она тоже должна анализировать параметры командной строки.

И имя файла с байт-кодом тоже брать оттуда.

как могла бы выглядеть команда запуска для файла с байт-кодом кумира?
sk -machine kumir moj_bait_kod.bytes
sk -machine evgeny ego_bait_kod.bytes

Посмотрел исходник, она не sk называется, а proba
https://tvoygit.ru/stein47/russian-virt … akefile#L5

Соответствующий кусок man qemu:

-machine [type=]name[,prop=value[,...]]
    Select the emulated machine by name. Use -machine help to list available machines.

    For architectures which aim to support live migration compatibility across releases, each release will introduce a new versioned machine type. For example, the 2.8.0 release introduced machine types "pc-i440fx-2.8" and "pc-q35-2.8" for the x86_64/i686 architectures.

    To allow live migration of guests from QEMU version 2.8.0, to QEMU version 2.9.0, the 2.9.0 version must support the "pc-i440fx-2.8" and "pc-q35-2.8" machines too. To allow users live migrating VMs to skip multiple intermediate releases when upgrading, new releases of QEMU will support machine types from many previous versions.

    Supported machine properties are:

accel=accels1[:accels2[:...]]
    This is used to enable an accelerator. Depending on the target architecture, kvm, xen, hax, hvf, nvmm, whpx or tcg can be available. By default, tcg is used. If there is more than one accelerator specified, the next one is used if the previous one fails to initialize.
vmport=on|off|auto
    Enables emulation of VMWare IO port, for vmmouse etc. auto says to select the value based on accel. For accel=xen the default is off otherwise the default is on.
dump-guest-core=on|off
    Include guest memory in a core dump. The default is on.
mem-merge=on|off
    Enables or disables memory merge support. This feature, when supported by the host, de-duplicates identical memory pages among VMs instances (enabled by default).
aes-key-wrap=on|off
    Enables or disables AES key wrapping support on s390-ccw hosts. This feature controls whether AES wrapping keys will be created to allow execution of AES cryptographic functions. The default is on.
dea-key-wrap=on|off
    Enables or disables DEA key wrapping support on s390-ccw hosts. This feature controls whether DEA wrapping keys will be created to allow execution of DEA cryptographic functions. The default is on.
nvdimm=on|off
    Enables or disables NVDIMM support. The default is off.
memory-encryption=
    Memory encryption object to use. The default is none.
hmat=on|off
    Enables or disables ACPI Heterogeneous Memory Attribute Table (HMAT) support. The default is off.
memory-backend='id'
    An alternative to legacy -mem-path and mem-prealloc options. Allows to use a memory backend as main RAM.

    For example:

-object memory-backend-file,id=pc.ram,size=512M,mem-path=/hugetlbfs,prealloc=on,share=on
-machine memory-backend=pc.ram
-m 512M

Migration compatibility note:

    as backend id one shall use value of 'default-ram-id', advertised by machine type (available via query-machines QMP command), if migration to/from old QEMU (<5.0) is expected.
    for machine types 4.0 and older, user shall use x-use-canonical-path-for-ramblock-id=off backend option if migration to/from old QEMU (<5.0) is expected.

For example:

-object memory-backend-ram,id=pc.ram,size=512M,x-use-canonical-path-for-ramblock-id=off
-machine memory-backend=pc.ram
-m 512M

cxl-fmw.0.targets.0=firsttarget,cxl-fmw.0.targets.1=secondtarget,cxl-fmw.0.size=size[,cxl-fmw.0.interleave-granularity=granularity]
    Define a CXL Fixed Memory Window (CFMW).

    Described in the CXL 2.0 ECN: CEDT CFMWS & QTG _DSM.

    They are regions of Host Physical Addresses (HPA) on a system which may be interleaved across one or more CXL host bridges. The system software will assign particular devices into these windows and configure the downstream Host-managed Device Memory (HDM) decoders in root ports, switch ports and devices appropriately to meet the interleave requirements before enabling the memory devices.

    targets.X=target provides the mapping to CXL host bridges which may be identified by the id provided in the -device entry. Multiple entries are needed to specify all the targets when the fixed memory window represents interleaved memory. X is the target index from 0.

    size=size sets the size of the CFMW. This must be a multiple of 256MiB. The region will be aligned to 256MiB but the location is platform and configuration dependent.

    interleave-granularity=granularity sets the granularity of interleave. Default 256KiB. Only 256KiB, 512KiB, 1024KiB, 2048KiB 4096KiB, 8192KiB and 16384KiB granularities supported.

    Example:

-machine cxl-fmw.0.targets.0=cxl.0,cxl-fmw.0.targets.1=cxl.1,cxl-fmw.0.size=128G,cxl-fmw.0.interleave-granularity=512k

-cpu model
    Select CPU model (-cpu help for list and additional feature selection)

Отредактировано Лис (2023-03-10 07:05:09)

0

47

Лис, мы начали с упрощенной машины, не с эмулятора реального процессора. И переданные в командной строке параметры сами ни во что не превратятся.

0

48

Евгений написал(а):

Лис, мы начали с упрощенной машины, не с эмулятора реального процессора.

Виртуальная машина КуМир-а не является реальным процессором.

Евгений написал(а):

И переданные в командной строке параметры сами ни во что не превратятся.

Верно, сделать им это помогут добровольцы, снабженные руководствами.

Кто-то захочет КуМир, кто-то Арм64, я хочу Интел64 (не все команды, а только чтобы "Здравствуй мир" запустить).
Виртуальные машины UEFI и Синхро ещё есть.

Представляешь, у твоего проекта уже есть один пользователь! Автору Рефал-а на такое достижение год потребовался.

Простота простой машины заключается в том, что в ней мало инструкций (не все),
мало механизмов процессоров (не все, например не нужна пока страничная память).

Да, можно сделать и как ты предлагаешь - ровно один ни к чему не привязанный вариант.

Расскажи, пожалуйста, как ты собираешься его применять дальше, и что с ним делать?

Отредактировано Лис (2023-03-10 07:25:07)

0

49

Лис, мои возможности ограничены. И я пока не знаю, как сделать такую универсальную машину.

Лис написал(а):

Расскажи, пожалуйста, как ты собираешься его применять дальше, и что с ним делать?

Ответ на этот вопрос очевиден, можно не озвучивать.

0

50

Евгений написал(а):

Ответ на этот вопрос очевиден, можно не озвучивать.

Будешь русским Кнут-ом. Проводить лекции студентам на пенсии, приезжать на конференции, давать интервью журналистам.

Евгений написал(а):

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

На уровне текстовых руководств программистам-наполнителям. В мейне при старте по ключам выбираем какой код будет выполнятся,
а инструкции (вместе с их опкодами) будут добавляться в разные исходники, написанные разными людьми,
но единообразно по одинаковым руководствам.

Отредактировано Лис (2023-03-10 08:48:21)

0

51

Лис написал(а):

На уровне текстовых руководств программистам-наполнителям. В мейне при старте по ключам выполняем какой код будет выполнятся,
а инструкции будут добавляться в разныеисходники разные, разными людьми,
но единообразно по одинаковым руководствам.

Звучит здорово и очень просто. Вопрос, как это реализовать в коде...

0

52

Евгений написал(а):

Посмотрел исходник, она не sk называется, а proba

До sk ей далеко, можно назвать lk - лягушонка в коробчонке.

0

53

Евгений написал(а):

Звучит здорово и очень просто.

Жду присвоения очередного звания очевидности.

Евгений написал(а):

Вопрос, как это реализовать в коде...

Что "это"?
Выбор одной функции из нескольких в зависимости от параметра командной строки?
Как расположить функции, по одной на каждую платформу в разные поддиректории?
Как написать текст-инструкцию для программистов?
  (это лучше всего попробовать начать делать на тхаб.рф, потому что она вики, заодно и политику редактирования проверим)

Отредактировано Лис (2023-03-10 08:56:59)

0

54

Не везет Лису. Один помощник, и тот туповатый. Эх...

0

55

Я не издеваюсь, ты же только что какие-то инструкции процессора добавил.

Значит можно это действие описать словами.

"Если вы хотите добавить инструкцию проца в вашу архитектуру, напишите такие строки туда-то потому что,
а такие строки там-то для того-то".

(действий разных два - "добавление инструкции" и "добавление архитектуры", но про это я уже раньше писал)

"Если вы хотите добавить новую архитектуру в эмулятор, придумайте имя, создайте директорию, такие-то файлы и такие-то функции скопируйте,
далее выполняйте туториал по добавлению инструкций ".

Это надо сделать.

Отредактировано Лис (2023-03-10 09:13:11)

0

56

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

0

57

Евгений написал(а):

Вопросов больше, чем ответов...

Чтобы иметь все вопросы отвеченными необходимо выполнить следующие действия:
1) выписать все вопросы в список
2) создать по топику на вопрос
3) обработать результаты обсуждений

На форуме это тоже можно проделать (не обязательно на Q&A сайте)

0

58

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

0

59

в качестве дочернего процесса

Разве не лучше (функцией dlopen) загрузить один из нескольких .so файлов в текущий процесс?
Это если прям ну очень хочется сократить размер кода в памяти.

Евгений написал(а):

у возможных участников не было конфликта имен

Не надо макросы так интенсивно использовать. Откуда у них конфликты, если у них у всех разные заголовочные файлы и разные Си-файлы?

Просто не надо функции экспортировать, и префиксы к именам можно добавлять.

https://stackoverflow.com/questions/688 … nt-c-files
«If these functions are only called locally in the same translation unit, you can make them static.»
«and have a struct with function pointers exported from each file.»

Отредактировано Лис (2023-03-11 23:21:13)

0

60

Лис написал(а):

Откуда у них конфликты, если у них у всех разные заголовочные файлы и разные Си-файлы?

Есть вероятность использования одних и тех же имен функций. Например: загрузить_ВМ(). Си файлы откомпилируются нормально, а линковщик выдаст ошибку.
А так да, придется использовать уникальные префиксы и суффиксы.

0


Вы здесь » ПО, ЭВМ и АСУ из Таможенного Союза » Проект "Виртуальные машины" » Первая реализация. Исходники.