Войти
ФлеймФорумПроЭкты

Ü (Programmiersprache) (57 стр)

Страницы: 154 55 56 57 58 59 Следующая »
#840
20:44, 20 дек. 2020

1 frag / 2 deaths
Ошибка компиляции:
https://carc.in/#/r/a57s

#841
21:13, 20 дек. 2020

kipar
А, то есть выборка по рандомному индексу возможна, но результатом опять будет юнион?

#842
22:02, 20 дек. 2020

1 frag / 2 deaths
Да. Основной плюс что ни у аргументов функций ни у переменных необязательно писать тип,  но все равно все статически типизированно.

#843
12:54, 21 дек. 2020

kipar
> сновной плюс что ни у аргументов функций ни у переменных необязательно писать
> тип
Ехал auto через auto, auto, auto, auto auto.

#844
(Правка: 14:04) 14:00, 21 дек. 2020

Panzerschrek[CN]
да, только и auto писать не надо. Так что синтаксис почти как у руби

def check(dog1, dog2)
  x = {dog1, dog2}.select(&.good?)
  x.each(&.gav)
end
но при этом компилятор всё проверяет.

---
и да, хипстеров конечно среди аудитории хватает, прям классических, со смузи в одной руке и вейпом в другой, но мне как-то пофиг.

#845
22:33, 21 дек. 2020

kipar
> да, только и auto писать не надо
Читаемость страдает. Поэтому я против языков, где тип не надо указывать в столь широких пределах.

#846
(Правка: 13:08) 13:07, 27 дек. 2020

По сырым указателям. Придумал примерный синтаксис для них.
Суть такова: есть некий стартовый символ (я пока не решил какой - кандидаты это @, #, $). Имя типа указателя состоит из этого символа и круглых скобок с типом элемента внутри. Операция преобразования ссылки в указатиель состоит из этого символа с постфикосом "<" и последующим выражением в круглых  скобках. Обратная операция выглядит точно также, но вместо "<" планируется ">".

Предварительный пример:

type PtrToInt = $(i32);
type PtrToPtrToInt= $($(i32)).

auto x= 0;
auto ptr_to_x= $<(x);
unsafe
{
  auto& x_ref= $>(ptr_to_x);
}

Почему синтаксис такой странный? Хочется специально сделать его отличным от C++, чтобы не было излишнего желания использовать сырые указатели.Круглые скобки нужны для того, чтобы не путаться в приоритетах префиксных/постфиксных операторов.

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

#847
(Правка: 22:34) 22:33, 27 дек. 2020

Panzerschrek[CN]
Такoй вопрос: Мoгу ли я переориентировать Ü под свою систему команд?
Второй вопрос: Перегрузку операторов можно сделать под любой юникод?

#848
22:35, 27 дек. 2020

Alikberov
> Мoгу ли я переориентировать Ü под свою систему команд?
Можешь, разрешаю.
Напиши свой backend к llvm, тогда не только Ü, но и другие языки сможешь в свою архитектуру компилировать.

#849
(Правка: 22:46) 22:43, 27 дек. 2020

Читaл бегло статью на Хабре, но пока ещё не совсем въехал в тонкости.
Имеются ли какие-то готовые средства, где, скажем, в XML можно описать все доступные ключевые комбинации машинного кода своей архитектуры?
По идее, нейросети должны уметь делать подобные вещи…

#850
22:46, 27 дек. 2020

Alikberov
https://llvm.org/docs/WritingAnLLVMBackend.html

#851
0:00, 28 дек. 2020
Чтo-то не могу вникнуть в некоторые нюансы.
Читаю туториал и мануал. Дошёл до условий (стр. 49) и не вижу, как я могу описать свои условия.
Например, вот такой псевдокод:
if ( x == y ) {
    // Блок THEN
} else {
    // Блок ELSE
}
    // OTHER
Должен кодироваться примерно так:
    CALL THEN     ; Вызов блока THEN
    CALL ELSE     ; Вызов блока ELSE
    ... OTHER ... ; Остальное
... ...  ...
THEN:
    CMP  X,Y      ; Сравниваем X и Y
    RETNZ         ; Возврат на «CALL ELSE», если X ≠ Y
    ADD  [SP],1   ; Смещение точки возврата на OTHER
    ...
    RET           ; Теперь возврат на OTHER
... ...  ...
ELSE:
    ...
    RET           ; Возврат на OTHER
Или же цикл:
while ( x == y ) {
    // Блок LOOP
}
    // OTHER
Таким же образом кодируется как:
    CALL LOOP     ; Вызов блока LOOP
    ... OTHER ... ; Остальное
... ...  ...
LOOP:
    CMP  X,Y      ; Сравниваем X и Y
    RETNZ         ; Возврат на OTHER если X ≠ Y
    SUB  [SP],1   ; Смещение точки на CALL LOOP
    ...
    RET           ; Теперь вернёмся и повторим CALL LOOP
На z80 я подобные трюки совершал:
7500 CD A0 75|CALL 0x75A0
.... .. .. ..|.... .. ..
75A0 7A      |LD   A,D
75A1 BB      |CP   A,E
75A2 C8      |RET  Z       ; Нормальный возврат
75A3 E3      |EX   (SP),HL ; Сейчас адрес возврата тут на 0x7503
75A4 2B      |DEC  HL
75A5 2B      |DEC  HL
75A6 2B      |DEC  HL
75A7 E3      |EX   (SP),HL ; Теперь адрес возврата снова 0x7500
75A8 .. .. ..|.... .. ..
75FF C9      |RET          ; Возврат и повтор вызова данного кода
Но это было трюком.
Тогда как у меня это практически единственный способ выполнения условий  как парадигма, к чему я пришёл за год проработки и менять что-то смысла не вижу…
#852
20:35, 28 дек. 2020

Alikberov
> не вижу, как я могу описать свои условия.
У тебя какие-то неортодоксальные условия. В llvm (и всех распространённых архитектурах) просто условный переход используется, что для ветвлений, что для циклов.

#853
22:00, 28 дек. 2020

Panzerschrek[CN]
> У тебя какие-то неортодоксальные условия.
B репозитории имеется файл библиотеки, который реализует ортодоксальные условия.
А именно, так как архитектуру я разрабатывал как масштабируемую, то программист может кодировать собственный набор инструкций общим числом от 17 до 161.

Например, операция ветвления по переносу кодироваться может как:

1234    FC DE BC|JC   0xBCDE
1237 .. .. .. ..|.... ... ...
Но работает вот так:
1234    FC      |CALL 0xFC00
1235       DE   |DB   0xDE
1236          BC|DB   0xBC
Первый байт - краткий вызов подпрограммы:
    .ORG 0xFC00
    IF (CF == FALSE)          // Если нет CF,
        RETURN [SP]+3;        // возврат с пропуском трёх байтов на 0x1237
    ADDR = [[SP] + 1];        // Иначе считываем младший байт 0xDE
    ADDR |= [[SP] + 2] * 256; // и следующий за ним старший байт 0xBC
    [SP] = ADDR;              // Помещаем новый адрес в стек
    RETURN;                   // и возвращаемся на новый адрес 0xBCDE
Таким образом, если программист нуждается в классических операциях ветвления, то он их описывает в служебном параграфе памяти, который может быть внутренней памятью с Гарвардским доступом и выполняться достаточно быстро.

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

P.S.: И Вы меня поставили в тупик, что я не могу заточить LLVM под свою парадигму… :-/

#854
17:12, 1 янв. 2021

С арифметикой указателей мне кое-что не совсем понятно.
Во-первых: стоит ли разрешить сложение указателя с знаковым числом и вычитание числа из указателя? Имеет ли это какой-либо смысл?
Во-вторых: какой тип должен быть у разности указателей? Знаковый или беззнаковый? А может ну её, эту разность и она никому не нужна?

Страницы: 154 55 56 57 58 59 Следующая »
ФлеймФорумПроЭкты