Recent Forum Posts
From categories:
page 1123...next »

В общем, с другим клиентом всё хорошо. Буду использовать его.

Re: проблемы с CVS by snarksnark, 12 Jan 2007 13:44

Ответ админа:

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

CVS/Entries: Permission denied

Это может быть вызвано тем, что первый checkout не завершился, и не отдаёт
файл на запись

Могу посоветовать две вещи:
1) попробовать повторить процедуру, перед этим удалить все полученные файлы
2) если не поможет - использовать другой клиент (например, от cygwin или
eclipse)|

Re: проблемы с CVS by dimstardimstar, 12 Jan 2007 11:27

Где-то за неделю до Нового Года, перестал работать cvs.
Подробности см. здесь

проблемы с CVS by snarksnark, 06 Jan 2007 13:30

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()
/* сброс ассемблера */

В четверг (07.12) мы обсудили некоторые аспекты нашего проекта, не совсем нам понятные, и решили продолжить дискуссию здесь.

1. Какие исходные данные имеются на момент начала построения DU-графа. Нужны данные, которых нет в CF-G, например, операнды инструкций; они имеются в Phx::…Instr, то есть в Фениксовских структурах. ЗНачит, мы не можем строить DU-Graph по нынешнему CFg. Может, следует добавить в последний ссылки на исходные объекты Феникса?

2. Вообще, как организовать процесс трансляции? Это будет какая-то функция, очевидно, но что ей передают, какие параметры? Как это все будет постороено в фазе, ведь нам в метод Execute передают Phx::Unit unit, который может быть функцией, и еще чем-то. Непонятно, как от этого нам плясать.

Some questions about bringing pieces together by (account deleted), 12 Dec 2006 12:20

Для битовых векторов, имхо, в ряде случаев лучше использовать не vector, а bitset. Потом, например, в алгоритме трансляции мы используем хэш для managed-объектов. По-моему STL в этом случае использовать нельзя.
Вроде для этой цели есть namespace'е System::Collections::Generic есть коллекция Hash или что-то вроде того.

Итак, раз мы используем STL предлагаю взять следующие шаблоны: для битовых векторов <vector>, для хэша <hash_map>.

Борис упоминул, что все-таки можно использовать STL в нашем проекте.

Итак на первый взгляд нам нужны:
1) Списки (причем, чтобы в элементе списка было 2 поля для пользовательских данных, это во многих случаях очень удобно)
2) Битовые вектора
3) Хэши

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

Использование STL by dimstardimstar, 21 Nov 2006 10:08

STL вполне можно использовать и с managed указателями. Если действительно надо, я могу постараться рассказать.
Правда самому надо будет это прояснить, но то что это можно - факт.

Вот мои соображения по этому поводу:
В Итаниуме:

  • есть такие хитрые инструкции с 4мя аргументами (1 управляющий предикат и 3 обычных регистра), например инструкция fma
  • есть инструкции с 2мя результатами, причем результатами могут быть 2 предиката, 1 предикат и 1 обычный регистр, 2 обычных регистра
  • есть инструкции, которые реально имеют 1-2 аргумента, но в компиляторе полезно ввести псевдо-аргументы для этих инструкций, причем число аргументов может быть довольно большим, например инструкция call

Так что предлагаю:

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

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

В Phoenix Phx::IR::Instr имеются поля отдельно для исходных операндов (SrcOpnd1..SrcOpnd6) и для аргументов-целей (DstOpnd1,Dstopnd2), причем суммарное число операндов ограничено (6 входных, два выходных).

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

Number and type of operands in DU_Oper class by (account deleted), 15 Nov 2006 08:48
Re: Managed C++
(account deleted) 13 Nov 2006 00:33
in discussion IA64 Codegen / General discussion » Managed C++

Что только буржуи не изобретут!
На 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 file

where:
file
A .dll, .exe, .netmodule, or .obj that was built with /clr.

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/vclrfTheUsingDirective.asp

Re: Managed C++ by (account deleted), 13 Nov 2006 00:33

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

  • 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 конструкцию.

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

Мысли о стиле кода by (account deleted), 12 Nov 2006 23:33

Так нам вроде ничего от PhxCFG не нужно. Все равно нумерацию нужно будет свою делать. Алгоритмы построения доминаторов/постдоминаторов написать не трудно. Так что я не вижу особой идеи наследоваться от PhxCFG.

Re: Phoenix-classes problems by dimstardimstar, 07 Nov 2006 17:27

В общем, столкнулся со следующей ситуацией.
CFG-граф работает у нас с CFG-узлами и CFG-ребрами.
Поэтому использовать родительские функции создания узлов и ребер не получается.
Приходится писать их аналоги. Но что именно делают родительские функции - загадка.
Документация говорит, что создают и инициализируют. Но, если мы создадим и инициализируем наиболее очевидным путём, то не будет ли у нас конфликтов? (например, с фениксовской нумерацией или с чем-нибудь подобным).
Логично было бы создать обычный node с помощью средств феникса, а затем, если б он поддерживал operator =, присвоить его CFG-узлу. Но, к сожалению, создатели Phoenix'а не создали такой возможности.
Может, конечно, я глобально туплю и есть простой выход, но я его не вижу.

P.S Кстати, обнаружилось, что фениксовская документация местами не соответствует реальности.

Phoenix-classes problems by snarksnark, 02 Nov 2006 22:01
Re: CVS
MICROMICRO 25 Oct 2006 13:03
in discussion IA64 Codegen / General discussion » CVS

а идея webcvs тебе не нравится?

Re: CVS by MICROMICRO, 25 Oct 2006 13:03
Re: CVS
dimstardimstar 25 Oct 2006 13:02
in discussion IA64 Codegen / General discussion » CVS

И эти ссылки я уже читал. Мне нужен именно cvs-client working under Windows, который умеет работать через прокси. Там я такого не нашел.

Re: CVS by dimstardimstar, 25 Oct 2006 13:02
Re: CVS
dimstardimstar 25 Oct 2006 12:59
in discussion IA64 Codegen / General discussion » CVS

Ну я пока залез на сервер через putty(ssh-client)+proxy и там сделал checkout (кстати, что-там не густо контента в сорцах, давайте уже пишите:-) ). Но через proxy+ssh работать невозможно, отклик очень долгий. Так что я бы хотел настроить именно cvs-клиента, чтобы он мог чекаутить и коммитить через прокси.

Re: CVS by dimstardimstar, 25 Oct 2006 12:59
Re: CVS
MICROMICRO 25 Oct 2006 12:51
in discussion IA64 Codegen / General discussion » 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

правда надо будет подумать где этот скрипт размещать.. и вообще как его настраивать…

Re: CVS by MICROMICRO, 25 Oct 2006 12:51

Вчера обнаружил, что всё не так просто.
Похоже, если мы собираемся использовать классы Феникса, то у нас может возникнуть несколько проблем. Например, все шаблоны STL естестественно unmanaged. Поэтому затруднена инкапсуляция их в managed классы(с объявлением ref class). Кроме того, похоже не возможно создать, например, set из указателей на managed классы. По-крайней мере, не очевидно как это делается. Вроде как VS2005 даёт какую-то альтернативу STL, что-то вроде System::Collections.
Кстати, посмотрю насчёт утилитки в Builder'е (вроде что-то видел такое).
В крайнем случае, придётся отказаться от STL, и делать всё через ^-указатели (очень надеюсь, что они работают также, как нормальные *-указатели)

Re: Managed C++ by snarksnark, 25 Oct 2006 09:33
page 1123...next »
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.