1. Если вы только начинаете программировать на ассемблере и не знаете с чего начать, тогда попробуйте среду разработки ASM Visual IDE
    (c) на правах рекламы
    Скрыть объявление

Указатель в описатель.

Тема в разделе "WASM.A&O", создана пользователем Indy_, 10 мар 2020.

  1. njeen

    njeen Active Member

    Публикаций:
    0
    Регистрация:
    26 мар 2017
    Сообщения:
    100
    Адрес:
    Ташлинск
    Если это верно для какого-то одного способа организации таблицы, это не значит, что это верно для всех. В закрытом и открытом хешировании ДОПУСКАЕТСЯ существование коллизий, и 'коллизий хэша не допускается от слова СОВСЕМ' в этом случае неверно
     
  2. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.938
    njeen, я рассматриваю хэш акь средство генерации уид. А если нам требуются просто ид-ы (без необходимости уникальности), то хэширование по большей части излишне == можно просто счётчики делать и уж тем более не нужны никакие квадраты.
     
    q2e74 нравится это.
  3. njeen

    njeen Active Member

    Публикаций:
    0
    Регистрация:
    26 мар 2017
    Сообщения:
    100
    Адрес:
    Ташлинск
    Аналогично, но индексы ('просто ид-ы') тоже получаются уникальными, и хеширование не излишне. Тот же самый уид, только короткий.
     
  4. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.938
    ид и уид могут быть одинаковой длины == способ формирования тут не основополагающий. хэши в основном требуются для сортировок строк большой и/ль переменной длины + с большим разбросом значений (хэшируемых данных). так же они хороши для систем безопасности и проверки целостности данных, где опять же речь идёт именно об уид-ах.
     
  5. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    3.256
    У меня есчо есть вопрос, по той же теме, но не про трансляцию, более общий. Сборка в памяти(бинарная трансляция).

    В моём случае буфер нельзя удерживать долго, если обернуть RWL то всё станет.

    Поток инструкция должен сохраняться в буфер и каждая инструкция дополняться ветвлением на общий стаб. Можно использовать общий буфер, взяв размер MAX_IP_LENGTH + BRANCH_LENGTH, выравненный на 4. Но тогда может образоваться затыка по профайлу при синхронном выделении памяти из глобал буфера. Так же в буфере будет рандом последовательность инструкций разных тредов. Хотелось бы собрать там их последовательность в порядке исполнения(хотя бы части cfg), это позволило бы избежать адресной трансляции(так как следующий блок следует за текущим). Вот только как это сделать синхронно и без поточных блокировок :dash1:
     
  6. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.938
    Indy_, обычно делается разделением режимов прогонки..

    1. ридмоуд == собирается статистика о запущенном бине и формируются гаджеты (блоки трансляции).
    2. активмоуд == ранее сформированные гаджеты начинают использоваться для изменения поведения бина.
     
  7. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    3.256
    UbIvItS,

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

    Получается если несколько потоков выполняют общий код, тогда пока происходит сборка для первого треда, остальные будут простаивать. Иначе будут повторения в буфере(утечка памяти). Наверно синхрон должен происходить не с одной инструкцией, а со всей ветвью. Так пока описывается одна инструкция, потоки ждут, но затем может быть ветвление не на первую инструкцию, таким образом это не линейная сборка. Если транслировать всю ветвь, то тоже не не ясно - пока выполняется сборка, другой поток может перейти к исполнению есчо не описанной части ветви(которая собирается в данный момент) и что тогда делать.. как то связывать или разбивать ветвь на части?
     
  8. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.938
    современные железки построены на асинхронных операциях. Ты же пытаешься соорудить синхронку, но такое катит лишь на одно-потоке и то далеко не всегда. Всем бы хотелось бы бт налету, однако ЖЪЪЪ физ возможности жестянок слишком скромны для таких амбиций. приложуха может себя вести по разному, но никто не мешает делать контроль входных данных, что урезает осетра на палитру её поведений.
     
  9. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    3.256
    UbIvItS,

    А какие принципиальные трудности могут быть ?

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

    Спин блокировка в описателе, её захват прежде анализа кода(диза) отменит повторную сборку. Не вижу возможных проблем. Задача весьма сложная, прежде чем браться за коденг нужно все алго и нюансы продумать, иначе придётся как всегда переписывать десятки раз.

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

    Объединение в линейные блоки теоретически позволит экономить на памяти, так как она сократится как минимум в 32 раза, если хранить для блока не описатели, а битовую карту(где маркированы начала инструкций).
     
    Последнее редактирование: 19 мар 2020
  10. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.938
    начнём с того, что у каждого много-потока есть своя логика блокировок и, накладывая свои, можно легко получить краши, дэдлоки и даже порчу файлов.