Carry - эмулятор., Блог. Поделиться Опции

[DmT]

Сообщение отредактировал DmT - 7.10.2010, 7:50

[Gray One]

Единственное что я понял из выше написанного, это

Что же такое Carry? Я хотел так собаку называть(голден ретривера), но собаки у меня пока нет, поэтому я так назвал свой проект.

я назвал Yana, в честь одной девушки - Яны.

Т.е. человеческим языком, это Carry даст нам возможность запускать эльфы на компьютере? Я правильно понял?

что работа идет полным ходом, и о прогрессе я теперь буду сообщать чуть ли не в режиме реального времени.

Это очень радует, только как бы все это не превратилось в подобные проекты как: ELF RPG и Aegis
Очень надеюсь что проект не забросят.

[DmT]

в подобные проекты как: ELF RPG и Aegis

Aegis не заброшен. На сколько мне известно Andy тоже воюет с оптимизацией и у него тоже еще много работы предстоит.

Добавлено позже (18.12.2009, 0:59):

Т.е. человеческим языком, это Carry даст нам возможность запускать эльфы на компьютере? Я правильно понял?

не просто запускать, но еще и отлаживать их, что актуально для разработчиков.

[baat]

ждёмс, надеюсь стабильние EDK выйдет...

[DmT]

надеюсь стабильние EDK выйдет...

будет входить в состав EDK. Собственно это будет отладчиком в EDK.

Сообщение отредактировал DmT - 18.12.2009, 6:44

[baat]

Gray One,

Это очень радует, только как бы все это не превратилось в подобные проекты как: ELF RPG и Aegis
Очень надеюсь что проект не забросят.

а откуда ты знаешь, что заброшено? мот я издателя ищу?

[Gray One]

а откуда ты знаешь, что заброшено? мот я издателя ищу?

К тому времени пока ты найдешь у меня уже будет голова седая и телефоном я уже пользоваться уметь не буду
В прочем это не один проект который был заброшен в ветке эльфов...

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

[DmT]

Gray One,
А ниче страшного, мы переберемся на androidы. Я лично на них ставлю будующее компании, ибо все остальные продукты медленно, но верно канули в лету.

[DmT]

хм... Сдал вектан, занялся эмулятором.
посидел посчитал. сейчас виртуальный процессор работает с тактовой 6 МГц, то есть на 1 инструкцию уходит 330 тактов.
Еще я посчитал сколько уходит тактов на инструкцию ADD(1), и сколько инструкций в её реализации: 17 тактов (ну с поправками до 27 где-то), а число инструкций - 27.
Путем хитрых расчетов(уже других, т.к. ADD не очень показательно) я вычислил, что статистически на моей машине за 1 такт выполняется примерно 1,13 инструкций. то есть при тактовой частоте в 2 ГГц за секунду выполнится 2,2 млрд. инструкций.
Для телефонного процессора всегда за 1 такт выполняется 1 инструкция, то есть чтобыб достичь 53 МГц нужно выполнять в секунду 53 млн. инструкций.
В итоге получается, что на 1 инструкцию ARM я могу потратить 42-43 инструкции IA32.
А сейчас на 1 инструкцию ARM - 367 инструкций IA32.
Цифры говорят сами за себя.

[Andy51]

DmT, чего-то ты перемудрил с эмуляцией. Нетрудно подсчитать из приведённых тобой данных, что понадобится процессор производительностью никак не ниже 17 ГГц :D И это ты ещё не учитывал затраты на задачи ОС. Лет через 6-7 такой процессор наверно и появится, который потянет твой эмулятор.

С другой стороны, имеем большую кучу эмуляторов GBA. Процессор в точности тот же, только частота в 3,5 раза меньше. И ведь работают же они, и требуют далеко не десятков гигагерц, а нормально работают даже на 600МГц xscale-ах.

Цифры говорят сами за себя. Попытки изобретения велосипедов не всегда заканчиваются велосипедами.

[DmT]

Andy51,
Ну дак по этому я и занялся JIT компиляцией
с JIT вполне можно 53 МГц сделать, без 17 ГГц процессора. А если еще и переписать работу с флагами CF, NF, ZF, VF на асме, то вообще сказочные частоты получить можно, ибо выставление флагов одна из наиболее затратных частей.
Так что ничего я не перемудрил.

Кстати, может быть поэтому JVM на мотороле столь медленная - из-за отсутствия JIT компиляции кода?

[DmT]

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

[Pyth_ON!]

Прочитал тему и слюнки потекли :)

[motoprogger]

JIT-компиляция Java, как я понял, на мобильных платформах непопулярна. У Google в андроиде вроде своя JVM, с несовместимым форматом исполняемых файлов (но есть конвертор), показывающая заметно лучшую производительность на мобильных платформах, но боюсь, их JVM нашему объёму оперативной памяти на P2K не светит

Насчёт JIT-компиляции ARM-кода под IA-32 - сразу предупреждаю, это сделает эмулятор несовместимым с процессорами других архитектур. То есть, его перенос на IA-64, amd64 или SPARC не будет тривиальным...

[DmT]

Насчёт JIT-компиляции ARM-кода под IA-32 - сразу предупреждаю, это сделает эмулятор несовместимым с процессорами других архитектур. То есть, его перенос на IA-64, amd64 или SPARC не будет тривиальным...

Дак весь перенос состоит в переписывании конструкторов функций-обработчиков инструкций ARM. Согласен с тем, что не тривиально, но вполне осуществимо.
План переноса такой: (возможно) изменяется синтаксис псевдо ассемблера. Соответственно функции генерирующие байткод из описания инструкции. Соответственно меняется конструктор функции-обработчика инструкции ARM на новый синтаксис псевдо ассемблера и возможно меняется сама структура конструктора(если новая платформа позволяет написать обработчик проще).

К тому же IA-64 и amd64 все еще поддерживают совместимость с x86 инструкциями. На счет SPARC не знаю, но ткните мне пальцем в того, кто использует платформу на SPARC для написания эльфов.

Сообщение отредактировал DmT - 27.1.2010, 16:23

[DOMAN]

объясните обычному юзеру на человеческом языке, к чему приведет ваш проект? и для чего он нужен? нашы телы мощьней станут? или это только для того чтоб еще производительней создавать эльфы?

[baat]

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

[DOMAN]

Т.е. Как я понял, это даст Вам, разработчикам, создавать более стабильные эльфы. Без глюков. И нас юзеров оставить без работы. :( хороший проект. :)

[baat]

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

[DmT]

Сегодня наконец начал разбираться с кодогенерацией... Ох ё, чего эти противные Intel наворотили в своем референсе...
http://www.intel.com/design/pentiumii/manuals/243191.htm
Час с @motoprogger потратили на то, чтобы только раскурить самые базовые вещи, о самой кодогенерации речи даже пока идти не может.
Информация для интересующихся:
В двух словах о инструкциях x86.
инструкции не имеют фиксированной длинны. Общий вид инструкции:

Код

[Instruction prefix] - есть не у всех инструкций, поле может занимать от 0 до 4 байт, может менять значение инструкции.
[Opcode] - основная часть того, что опредляет что же за инструкция перед нами. Занимает от 1 до 2 байт, но еще 3 бита могут храниться в следующем поле.
[ModR/M] - Занимает 1 байт, если вообще используется. Делится на три подполя:
----[Mod] - 2 бита, которые определяют что из себя представляют операнды инструкции(регистр/память)
----[Reg/Opcode] - 3 бита. Во-первых те самые 3 бита дополнительных для [Opcode]. Во вторых информация об операндах(номер регистра помеченного в описании инструкции как "r").
----[R/M] - 3 бита. Так же определяет информацию об операндах. Если [Mod] соответствует операндам-регистрам, то тут будет номер регистра помеченного "r/m", если [Mod] соответствует ситуации в которой фигурирует память, то в этом подполе + возможно в следующем поле содержится информация о методе вычисления указателя.
[SIB] - 1 байт если запрошен. Не очень понял что именно он делает.
[Dispalcement] - может быть 1, 2 или 4 байта. Если указано, что в качестве операнда выступает указатель на память, вычисленный через регистры, и к нему прибавляется некая констнта, то эта константа задается этим полем.
[Immediate] - может быть 1, 2 или 4 байта. Если в инструкции явно задана константа (не для адресации), то она задана через такую формулу.

Завтра буду учиться на бумажке составлять инструкции. компилятор в голове:)


Сообщение отредактировал DmT - 31.1.2010, 8:11

[DmT]

Заболел. Точнее вернулась старая хроническа болезнь - холицестит. Седня вообще нет желания напрягать мозг, уж очень [синоним "плохо"] всяким органам.

[baat]

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

[DmT]

выздоравливай...

Спасибо.

ждём разработок...

все ждут. А я потихоньку двигаюсь к созданию самопального ассемблера.


Сообщение отредактировал DmT - 31.1.2010, 8:11

[DmT]

/me начинает тихонько ненавидеть x86

Сегодня написал один конструктор для Thumb - AND. Осталось написать еще 52. Плюс для ARM несколько.
Команда AND получилась длинной в 9 инструкций. Для сравнения, в варианте с интерпритацией она заниммает 37 инструкций.

PS. Выдержка из конструктора AND.

Spoiler:

Код

    Code+=GenerateX86_MOV_32_REG_IMEM(Code, EBX, GetPtrOfRegisterPtr(Ctx, d));
    Code+=GenerateX86_MOV_32_REG_RMEM(Code, EAX, EBX);
    Code+=GenerateX86_MOV_32_REG_IMEM(Code, ECX, GetPtrOfRegisterPtr(Ctx, m));
    Code+=GenerateX86_MOV_32_REG_RMEM(Code, ECX, ECX);
    Code+=GenerateX86_AND_32_REG_REG(Code, EAX, ECX);
    Code+=GenerateX86_SETZ_IMEM(Code, (uint32*)&(_ZF));
    Code+=GenerateX86_SETS_IMEM(Code, (uint32*)&(_NF));
    Code+=GenerateX86_MOV_32_RMEM_REG(Code, EBX, EAX);
    Code+=GenerateX86_RETN(Code);

[close]

[motoprogger]

Сюда бы для сравнения строчку на ассемблере ARM и её реализацию при интерпретации (к чему оно сводится) и с компиляцией - в двух рядом расположенных столбцах... наш движок таблицы случайно не поддерживает?

[DmT]

motoprogger,
На счет таблицы ты погорячился конечно... Давай я так напишу.

Spoiler:

Вот так пишется команда на ARM/Thumb:

Код

    AND R0, R1

Итого 1 инструкция.
Вот так её эмулирую я на x86

Код

;ptr1 = указатель на ячейку таблицы переадресации для регистра 1(R0)
;ptr2 = указатель на ячейку таблицы переадресации для регистра 1(R1)
;ptr3 = указатель на флаг нуля (ZF)
;ptr4 = указатель на флаг знака(отрицательного числа) (NF)
    mov ebx, [ptr1]
    mov eax, [ebx]
    mov ecx, [ptr2]
    mov ecx, [ecx]
    and eax, ecx
    setz ptr3
    sets ptr4
    mov [ebx], eax
    retn

Итого 9 инструкций.
А вот так работает она же в режиме интерпритации:

Код

push    ebp
mov     ebp, esp
push    ebx
sub     esp, 8
mov     [ebp+var_8], ecx
mov     [ebp+var_C], edx
mov     edx, [ebp+arg_0]
mov     eax, [ebp+var_8]
add     edx, 10h
mov     eax, [eax+edx*4+8]
mov     ecx, [ebp+arg_0]
mov     edx, [ebp+var_8]
add     ecx, 10h
mov     edx, [edx+ecx*4+8]
mov     ecx, [edx]
mov     ebx, [ebp+var_C]
mov     edx, [ebp+var_8]
add     ebx, 10h
mov     edx, [edx+ebx*4+8]
mov     edx, [edx]
and     edx, ecx
mov     [eax], edx
mov     eax, [ebp+var_8]
mov     byte ptr [eax+128h], 0
mov     edx, [ebp+arg_0]
mov     eax, [ebp+var_8]
add     edx, 10h
mov     eax, [eax+edx*4+8]
mov     eax, [eax]
test    eax, eax
setz    dl
mov     eax, [ebp+var_8]
mov     [eax+129h], dl
add     esp, 8
pop     ebx
leave
retn    0Ch

Итого ДОФИГА команд.

[close]

Надо систему облаков кода написать...

Сообщение отредактировал DmT - 2.2.2010, 7:51

[DmT]

На тему котогенератора - http://www.liveinternet.ru/users/3428864/post115304976/play

[DmT]

Только что дописал часть ответственную за обслуживание компиляции(все, кроме конструкторов инструкций).
Теперь надо это все отладить и написать еще ~60 конструкторов (не считая ARM).

[DmT]

Весь день переезжал на новую IDE. Устал от глюков Code::Blocks - решил сменить IDE. По совету @Andy51 поставил CodeLite. Еще пробовал NetBeans 6.8 для C++. Но как то с ним не подружился. А CodeLite вроде ниче... Весь день конфигурировал, подгонял под себя, перетаскивал проект. вроде все перетащил, компилируется. Единственное, что меня смущает - кажется он не умеет анализировать структуры и код вообще. Ну в частности он не раскрывает список полей структуры когда я пишу например так:

Код

THUMB_INSTR_T Inst;
Inst.

Хотя более другие IDE (типа Borland, VC ) тут же бы предложили бы список вариантов состоящий из полей структуры THUMB_INSTR_T...

Или я дурак или лыжи не едут?

Сообщение отредактировал DmT - 6.2.2010, 20:33

[Andy51]

DmT, у них на сайте в списке фич стоит "Sophisticated database-based Code Completion mechanism". Если это про то, что ты говоришь - то не едут :)

[DmT]

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

[DmT]

Переписал главную функцию процессора - "выполнение такта" на новый лад, т.е. с применением JIT компиляции. Теперь работает следующим образом:
Если код по этому адресу скомпилирован и корректен то выполняем его
Иначе пробуем скомпилировать:
Если новый код скомпилирован(успешное выполнение операции) то выполняем его
Иначе пытаемся интерпретировать:
Если интерпретирование успешно: либо сдвигаем конвеер, либо сбрасываем.
Иначе - исключение

Потерял в прозводительности в режиме интерпретации из-за такого ветвления 0,15-0,2 Мгц (2,5% кароче). Теперь где-то 5,8-5,85 Мгц для интерпретации, но это все равно относительно не плохо. Производительность для компиляции еще не тестировал.

Добавлено позже (8.2.2010, 2:08):
Заметка о компиляции:
Во главе всей части относящейся к компиляции стоит структура CODEGENERATOR_T. В её состав входят: специальный пул памяти зарезервированной под код(за исходный код внутреннего менеджера для этого пула благодарю http://rtportal.upv.es/rtmalloc/), поле Error отвечающее за предоставление кода ошибки в случае чего, а так же работа с "облаками" кода.
На "облаках" напишу подробнее. Я не очень помню откуда взялся сам термин в проекте (Cloud), но в принципе почему бы ему так не называться... Если коротко: в адресном пространстве код может находится не где угодно, а только в устройствах с памятью (для телефона - IRAM, RAM, ROM, IROM). Такую функциональность предоставляет модуль YanaBus(о нем наверное отдельно напишу): существует массив устройств, для каждого из которых определены базовый адрес, размер и выделена память. Но хранить скомпилированный код вместе с оригинальным, т.е. в устройстве YanaBus, не правильно. Поэтому нужна некая другая структура подобная устройсву(BASEDEVICE_T), но для скомпилированного кода. Такую структуру я назвал CLOUD_T. Каждое облако имеет соответствующее устройство YanaBus(совпадает базовый адрес и размер), но в отличии от устройства содержит не указатель на память, а две таблицы переадресации (две для Thumb и ARM, разделено, чтобы при предкомпиляции не возникало проблем) на скомпилированный код.
Как-то так.

Сообщение отредактировал DmT - 7.2.2010, 20:35

[DmT]

Есть желающие помочь проекту?
нужно желание, знание ассма под x86 (и умение подстраиваться под необычный синтаксис), и свободное время.

на текщий момент готово 10 генераторов. ктоб знал как мне лень ими заниматься!

Spoiler:

CODE

const thumb_record_t thumbtable[t_op_max] = {
{(thumbophandler_t)dothumbadc , (thumbopgenerator_t)generatethumbadc},
{(thumbophandler_t)dothumbadd1 , (thumbopgenerator_t)generatethumbadd1},
{(thumbophandler_t)dothumbadd2 , (thumbopgenerator_t)generatethumbadd2},
{(thumbophandler_t)dothumbadd3 , (thumbopgenerator_t)generatethumbadd3},
{(thumbophandler_t)dothumbadd4 , (thumbopgenerator_t)generatethumbadd4},
{(thumbophandler_t)dothumbadd5 , (thumbopgenerator_t)generatethumbadd5},
{(thumbophandler_t)dothumbadd6 , (thumbopgenerator_t)generatethumbadd6},
{(thumbophandler_t)dothumbadd7 , (thumbopgenerator_t)generatethumbadd7},
{(thumbophandler_t)dothumband , (thumbopgenerator_t)generatethumband},
{(thumbophandler_t)dothumbasr1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbasr2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbb1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbb2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbbic , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbbkpt , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbblx1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbblx2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbbx , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbcmn , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbcmp1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbcmp2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbcmp3 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbeor , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbldmia , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbldr1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbldr2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbldr3 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbldr4 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbldrb1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbldrb2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbldrh1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbldrh2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbldrsb , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbldrsh , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumblsl1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumblsl2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumblsr1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumblsr2 , (thumbopgenerator_t)null},
{(thumbophandler_t)null , (thumbopgenerator_t)null},
{(thumbophandler_t)null , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbmov1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbmov2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbmov3 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbmul , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbmvn , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbneg , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumborr , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbpop , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbpush , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbror , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbsbc , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbstmia , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbstr1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbstr2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbstr3 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbstrb1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbstrb2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbstrh1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbstrh2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbsub1 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbsub2 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbsub3 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbsub4 , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbswi , (thumbopgenerator_t)null},
{(thumbophandler_t)dothumbtst , (thumbopgenerator_t)null}
};

[close]

_______ред________
Ну раз желающих нет, то нет. Запомнили.

Сообщение отредактировал DmT - 10.2.2010, 21:26

[baat]

DmT, желающие может и есть... а вот...

свободное время

увы думаю не у всех...

я бы хотел помочь но...

умение подстраиваться под необычный синтаксис

боюсь у меня нет...

Сообщение отредактировал baat - 12.2.2010, 14:44

[DmT]

Кто-нибудь разбирается в загрузке файлов формата ELF?
У меня есть проблемы с этим(

уже не надо.

Сообщение отредактировал DmT - 28.3.2010, 17:12

[DmT]

Очень плохие новости. Неделю назад у меня полетел ноутбук, а вчера еще и настольный компьютер. Теперь я по факту не имею возможности разрабатывать Кэрри. Да и вообще спасение того, что я уже написал, то есть примерно 2/3 проекта, под вопросом, так как полетел у меня винт.

[Honda]

капец( Будем надеяться, его можно еще восстановить

[DmT]

Ну надейстесь.

[DmT]

ЛИКУЙТЕ! Я его поднял (второй винт). Дело было в кривых руках разработчиков виндового драйвера ntfs.sys

[SaniaZ]