В общем, с другим клиентом всё хорошо. Буду использовать его.
Ответ админа:
Если это однократный случай - то такое может быть из-за блокировок,
например, от параллельного коммита.
Клиент ожидает когда блокировка снимется.
CVS/Entries: Permission denied
Это может быть вызвано тем, что первый checkout не завершился, и не отдаёт
файл на запись
Могу посоветовать две вещи:
1) попробовать повторить процедуру, перед этим удалить все полученные файлы
2) если не поможет - использовать другой клиент (например, от cygwin или
eclipse)|
Где-то за неделю до Нового Года, перестал работать cvs.
Подробности см. здесь
in discussion IA64 Codegen / General discussion » Some questions about bringing pieces together
1) На момент построения DU-Графа есть Phx::Instr и SSA. То есть нудно распарсить все инструкции и их операнды. Для каждой инструкции создать Oper_Node или Phi_Node, построить DU_Obj для каждого операнда (опять же есть нужно). Потом сделать связь инструкций и новых операций через хэш-таблицу, и вторым проходом достроить дуги DU-Графа между новыми операциями и фи-узлами. То есть действия, практически аналогичный трансляции CFG.
2) Я предлагаю процесс трансляции органицовать как медот класса Proc. Это будет логичнее всего. Создаем proc, а дальше последовательно вызываем ее методы, которые представляют из себя те или иные преобразования:
Proc ^ proc = new Proc()
proc->Translate()
/* после этого появляются CFG и DUG */
proc->Optimize()
/* некоторые оптимизации */
proc->Schedule()
/* планирование операций в широкие команды */
proc->RegAlloc()
/* распределение регистров*/
proc->Emit()
/* сброс ассемблера */
in discussion IA64 Codegen / General discussion » Some questions about bringing pieces together
В четверг (07.12) мы обсудили некоторые аспекты нашего проекта, не совсем нам понятные, и решили продолжить дискуссию здесь.
1. Какие исходные данные имеются на момент начала построения DU-графа. Нужны данные, которых нет в CF-G, например, операнды инструкций; они имеются в Phx::…Instr, то есть в Фениксовских структурах. ЗНачит, мы не можем строить DU-Graph по нынешнему CFg. Может, следует добавить в последний ссылки на исходные объекты Феникса?
2. Вообще, как организовать процесс трансляции? Это будет какая-то функция, очевидно, но что ей передают, какие параметры? Как это все будет постороено в фазе, ведь нам в метод Execute передают Phx::Unit unit, который может быть функцией, и еще чем-то. Непонятно, как от этого нам плясать.
Для битовых векторов, имхо, в ряде случаев лучше использовать не vector, а bitset. Потом, например, в алгоритме трансляции мы используем хэш для managed-объектов. По-моему STL в этом случае использовать нельзя.
Вроде для этой цели есть namespace'е System::Collections::Generic есть коллекция Hash или что-то вроде того.
Итак, раз мы используем STL предлагаю взять следующие шаблоны: для битовых векторов <vector>, для хэша <hash_map>.
Борис упоминул, что все-таки можно использовать STL в нашем проекте.
Итак на первый взгляд нам нужны:
1) Списки (причем, чтобы в элементе списка было 2 поля для пользовательских данных, это во многих случаях очень удобно)
2) Битовые вектора
3) Хэши
Предлагаю здесь обсудить, каким образом можно создавать и использовать объекты упомянутых классов в нашем проекте.
STL вполне можно использовать и с managed указателями. Если действительно надо, я могу постараться рассказать.
Правда самому надо будет это прояснить, но то что это можно - факт.
in discussion IA64 Codegen / Framework » Number and type of operands in DU_Oper class
Вот мои соображения по этому поводу:
В Итаниуме:
- есть такие хитрые инструкции с 4мя аргументами (1 управляющий предикат и 3 обычных регистра), например инструкция fma
- есть инструкции с 2мя результатами, причем результатами могут быть 2 предиката, 1 предикат и 1 обычный регистр, 2 обычных регистра
- есть инструкции, которые реально имеют 1-2 аргумента, но в компиляторе полезно ввести псевдо-аргументы для этих инструкций, причем число аргументов может быть довольно большим, например инструкция call
Так что предлагаю:
- ввести фиксированный общий массив для аргументов и результатов, состоящий из 6ти полей (точно должно хватить для обычных инструкций), далее просто каким-то образом помечать, является ли элемент массива аргументом или результатом
- ввести специальный тип инструкции с переменным числом агрументов и результатов, можно реализовать в виде списка.
Решение создавать массив из 6ти элементов вместо списка для обычных инструкций вызвано тем соображением, что аргументы инструкций обходятся очень часто, так что нужно думать и о времени компиляции. И вообще, принцип такой - когда можно ограничится конечным числом элементов, то лучше использовать массивы.
in discussion IA64 Codegen / Framework » Number and type of operands in DU_Oper class
В Phoenix Phx::IR::Instr имеются поля отдельно для исходных операндов (SrcOpnd1..SrcOpnd6) и для аргументов-целей (DstOpnd1,Dstopnd2), причем суммарное число операндов ограничено (6 входных, два выходных).
Вопрос - следует ли в нашей реализации различать исходные аргументы от конечных, и сколько операндов делать (переменное число, может быть?)
Что только буржуи не изобретут!
На MSDN нашел хелп по директиве #using, которая в проект добавляет dll-ку, т.е. именно так phx.dll попадает в наш код!
А я думал - где хэдэр, где хэдэр?..
C/C++ Preprocessor Reference
The #using Directive
Imports metadata into a program that will use the Managed Extensions for C++.
#using filewhere:
file
A .dll, .exe, .netmodule, or .obj that was built with /clr.
in discussion IA64 Codegen / General discussion » Мысли о стиле кода
Итак, какие решения насчет общего стиля и концепций я принял для себя, а значит, и для всех. Думаю, они правильные.
- 1. Придется использовать managed указатели (^, ref и т.п.), потому что другого выхода, похоже нет.
Цитата из PhxDoc.chm:
Managed mode <…>
The managed build of the Phoenix framework saves its results into a few DLL assemblies; the main one is phx.dll
If you are building tools using a 'managed' compiler – one that targets the .NET Framework (e.g., Visual Basic .NET,
Visual C#, Visual J#, or Visual C++) – your tool uses the Phoenix code from these assemblies.
Unmanaged Mode
The unmanaged build saves its results into a few native libraries; the main one is phx.lib
If you are building tools using an 'unmanaged' compiler – one that can target the Windows
operating system directly (Visual C++, for example) – your tool uses the Phoenix code from these libraries.
Поскольку файла phx.lib нет ни в RDK, ни в вебе, нам остается использовать phx.dll и все, что из этого следует.
Возможность компиляции кода другими компиляторами отпадает, а также следующий пункт
- 2. STL задействовать, похоже, не удастся.
Проблема обсуждалась в http://cmplr.wikidot.com/forum/t-912/managed-c
В http://cmplr.wikidot.com/ia64-codegen:cfgtranslation предложено решение - использовать template
System::Collections::Generic::List<> как альтернативу STL. Думаю, это хороший выход, правда, придется учить новый синтаксис.
- 3. Phx.dll не удалось распотрошить.
Теоретически есть возможность получить по dll-ке список экспорта в .lib файл. шарящие люди мне сказали, что мистическая implib.exe
может это сделать. Однако у меня не получилось - пишет No exports. Кстати, утилитка оказалась из BCBuilder'а. Это еще раз побуждает
нас использовать managed и иже с ним.
- 4. Для невключения хэдэров множественное число раз при сборке не используем #pragma once, а юзаем #ifndef … #endif конструкцию.
Просто для единообразия вида. Пример - смотри уже написанные хэдеры, первые две строчки и последнюю.
Так нам вроде ничего от PhxCFG не нужно. Все равно нумерацию нужно будет свою делать. Алгоритмы построения доминаторов/постдоминаторов написать не трудно. Так что я не вижу особой идеи наследоваться от PhxCFG.
В общем, столкнулся со следующей ситуацией.
CFG-граф работает у нас с CFG-узлами и CFG-ребрами.
Поэтому использовать родительские функции создания узлов и ребер не получается.
Приходится писать их аналоги. Но что именно делают родительские функции - загадка.
Документация говорит, что создают и инициализируют. Но, если мы создадим и инициализируем наиболее очевидным путём, то не будет ли у нас конфликтов? (например, с фениксовской нумерацией или с чем-нибудь подобным).
Логично было бы создать обычный node с помощью средств феникса, а затем, если б он поддерживал operator =, присвоить его CFG-узлу. Но, к сожалению, создатели Phoenix'а не создали такой возможности.
Может, конечно, я глобально туплю и есть простой выход, но я его не вижу.
P.S Кстати, обнаружилось, что фениксовская документация местами не соответствует реальности.
а идея webcvs тебе не нравится?
И эти ссылки я уже читал. Мне нужен именно cvs-client working under Windows, который умеет работать через прокси. Там я такого не нашел.
Ну я пока залез на сервер через putty(ssh-client)+proxy и там сделал checkout (кстати, что-там не густо контента в сорцах, давайте уже пишите:-) ). Но через proxy+ssh работать невозможно, отклик очень долгий. Так что я бы хотел настроить именно cvs-клиента, чтобы он мог чекаутить и коммитить через прокси.
хм.. никогда не работал по ssh через прокси, но думаю разобраться в этом помогут статьи
http://sourceware.org/ml/kawa/2003-q3/msg00069.html
http://sourceware.org/ml/kawa/2003-q3/msg00069.html
Также… эту проблему думаю можно обойти через web-cvs
http://www.freebsd.org/projects/cvsweb.html
правда надо будет подумать где этот скрипт размещать.. и вообще как его настраивать…
Вчера обнаружил, что всё не так просто.
Похоже, если мы собираемся использовать классы Феникса, то у нас может возникнуть несколько проблем. Например, все шаблоны STL естестественно unmanaged. Поэтому затруднена инкапсуляция их в managed классы(с объявлением ref class). Кроме того, похоже не возможно создать, например, set из указателей на managed классы. По-крайней мере, не очевидно как это делается. Вроде как VS2005 даёт какую-то альтернативу STL, что-то вроде System::Collections.
Кстати, посмотрю насчёт утилитки в Builder'е (вроде что-то видел такое).
В крайнем случае, придётся отказаться от STL, и делать всё через ^-указатели (очень надеюсь, что они работают также, как нормальные *-указатели)