FASM Прикрутить кнопку на стандартное окно...

Прекрасный код, нечего оптимизировать. Лучше от замены cmp eax,0 на or eax,eax не станет, ехе файл все равно выравнивается на большое кол-во байт, процессору все равно, виндовс имеет сотни мегабайт мусора, а читабельность сильно ухудшится.

Я прям обзавидовался. Респект!

 

Спасибо конечно... (но уверен... ещё подскажут умные моменты... )

 

rococo795

Понимаете, что это у вас механизм get-set. Тоесть это серия чтения и записи, которую сложно оптимизировать и главное что никакого алгоритма в этом не имеется. Так полагаю что установка EOF есть унылое говно и никак вам не поможет для поднятия скула. Это элементарный примитив, без обид.
В этом не содержится никакой инфы - можно как угодно отображать файл, записывать и соответствующему смещению етц - это всё примитив.
Это так полагаю тема работа с файлами" из ньюб. Нет ничего плохого или странного в таком вопросе, но вы должны понять что у вас свой разум.

 

Даже намёка на какие то обиды быть не может.... (это хобби - не по возрасту... ну и немного автоматизировать мыслишки)

Не знаю что такое ньюб.... Я ничего нигде не смотрел. Только тут спрашивал...

Хех... Это понято давно давно давно... У меня он свой... Разум он такой!!! Если он есть - то сразу его может и не быть!!!! И тут от меня нет абсолютно никаких соревнований!!!! (Понадобился момент работы с файлами и большими и маленькими - спросил у гугла - а он сказал, что есть много много разных программистов - но они либо слишком высокого уровня либо слишком низкого - и нигде на фасме не оставили кодесок по этому делу... - а мне то нужен был такой!!! А разум - да!!! Я согласный.... У меня его не может быть в этом направлении нормальным... говорил не один раз... но я его компенсирую разумом в плане - на какую ножку упасть чтоб вложиться и попасть по бороде в направлении чуть сверху и влево - если прямой правый.... ну там... могу рассказать чтоб иногда, когда музыкант играет медленную красивую музыку использовал девятую ступень.... (на гитаре в басАх).. то есть в любимом Ля миноре - играешь Си...(и Си тут - ваще ни разу не язык ))))) )... ну ещё могу поговорить не несколько тем на высоком уровне......
А тут - я отдыхаю....
И сильно благодарен каждому - за подсказки.... (и вообще навсегда благодарен l_inc, Mikl___ , rmn ) ... так как именно они, в своё время уделили мне часть своего времени и в личке давали чёткие подсказки детского уровня!!!! - не каждый кодер, такого уровня, найдёт в себе силы и терпения говорить, писать и править - "детский" кодес....)

 

rococo795

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

> но они либо слишком высокого уровня либо слишком низкого

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

 

> не каждый кодер, такого уровня, найдёт в себе силы и терпения говорить, писать и править - "детский" кодес....

Частично я согласен. Вот только кодерами приведённых вами людей назвать нельзя, так же как и гугл

 

К сути....
1. Есть файл гигов 4...
2. Этот файл буду просматривать вдоль и поперёк, высчитывать кучу смещений... Из общей массы буду формировать структуру файла....
3. Как логичнее делать????
3.1 Выделяю память под исходный файл и работаю с ним через неё...
3.2 А куда девать высчитанные смещения и части массива исходного файла??? Резервировать место в программе в неинициализированных данных??? Записывать в созданный промежуточный файл а потом уже из него читать в окончательный новый??? Или выделить память как и для исходного, но под каждую часть файла (штук 10 памятей от 200 байт до 100 мб) собрать в этих памятях части файла и потом из этих памятей записать новый файл????
Как поступают в таких случаях грамотные люди???

 

Не стоит забывать, что в нормальных ОС есть такое понятие, как дисковый кэш, поэтому ОС обеспечит достаточно быстрое чтение вдоль и поперёк файла.
Однако вы можете реализовать свой дисковый кэш, в котором будете хранить блоки файла, а старые блоки синхронизировать с диском.
Помните только два правила:
1. Жёсткие диски любят последовательное чтение. Чем больше данных вы прочли с HDD последовательно, тем меньше времени уходит на поиск нужного сектора на диске.
2. Жёсткие диски любят читать/писать помногу. Чем больше размер блока для разового вычитывания/записи вы используете (32М, 64М), тем меньше нагрузка по IO.

 

SadKo,
Понял... Спасибо..

 

3.2

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

И обращаться к элементам структуры будешь несложно,
например, элемент номер 13, у него параметры: смещение куска в исходном файле 100500, длина куска = 1337.

Даже не столько с помощью директив Фасм для структур, сколько с помощью задания простого массива данных, где длина массива = колво_элементов * размерность_элементов.
В данном случае, размерность каждого элемента структуры (массива) будет 2*4, т.к. параметров у этого элемента 2, и размерность каждого 4 байта.

Можно сразу указать массив в виде DUP, наподобие db 99999 dup (?), или db 99999 dup(0FFh).
(?) более предпочтителен, чтобы на диске в Ехе место не занимать (будет только в заголовке отмечено, и память под массив будет выделяться уже при загрузке ехе виндой)

Это удачно подходит под двухпроходный аспект работы с файлами т.е. первым проходом мы "шерстим" исходный файл и ничего не пишем в результирующий, вторым проходом - если все проверки пройдены - только извлекаем куски во второй файл.

 

Вот задача такая ... да.. Спасибо...

 

tararara1 dd ?
tararara2 dd ?

можно как то в коде переделывать tararara1 в tararara2, путём прибавления к 31h единицы и получения в коде обращения к tararara2 .... а потом ввычитания из 32h единицы и обращения к tararara1 .... либо не прибавления а замены 31h на 32h.... ???

 

Проще нужно. Не нужно ничего переделывать. Пусть переменная используется 1 раз, ничего страшного. Создай массив таких переменных; зная их размер (4 байта), можно всегда адресовать нужную, умножив ее порядковый номер на 4.

Два пути:

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

Потрачено N времени, усилий, и что вы таки думаете? Верно, в привычку либо входит создание работающего кода (т.е. выполнение поставленной цели), либо - создание 1337 h4ck3r'ских уродцев, демонстрирующих дико закрученный 1337-ололо-код, но в реальной обстановке (читай, задачах) нежизнеспособных.

Так что делай не просто просто, а максимально просто. Делай, чтобы оно работало. Оптимизация должна быть только на алгоритмах, а не на их реализации в коде.

p.s. видимо, все же для твоей задачи лучше взять что-то более высокоуровневое, наподобие Си. чтобы видеть (работать над) алго, а не выкрутасничать с реализацией A=B+C. как это называется по умному, неверная декомпозиция задачи?

 

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

так что прямо не знаю что сказать. поздравлю с тамошним праздником, если только. )

 

Я полностью согласен.. И я так и делаю... Просто ещё не дописав то что задумал - само собой видится реально более компактное решение (ни капли не изврат!!)...
Не не!! Только асм!!! ))))) (он мне теперь то понятней - на другие языки смотрю вообще как на крякозяблы - силов вникать в них уже нет... да и по душе асм-фасм...) и самое главное - я никуда не спешу... отдыхаю для себя... ничего не лимитирует... Знаю теперь одно... чтобы сочинить более менее простой алгоритм - нужно самое главное знать не язык програмирования... а тот вопрос, который захотел автоматизировать.... только когда его понял более менее - понимаешь что как куда и зачем... - это главное....
Спасибо за наводку про 4 байта... попробую ради интереса...

 

В корне не согласен. Выбор оптимального алгоритма - только первый шаг оптимизации - высокоуровневая оптимизация.
Далее идёт оптимизация на среднем уровне путём вынесения различных вычислений из циклов.
Потом - оптимизация на низком уровне: векторизация математики и т.д.
Оптимизация на низком уровне может ускорить оптимальный алгоритм ещё минимум раза в три.

 

Это приведен идеальный сферический программинг в вакууме. В этом топике, не хочу никого обижать, есть траблы и с выбором оптимального алгоритма, и с оптимизацией на низком уровне.

Где-то на форуме пробегал топик с работой с winsock; там автор "утонул" в регистрах и стеке, и ему верно было предложено сначала сделать работающий прототип на Си, чтобы видеть алгоритм, и уже потом его причесывать на ассемблерном уровне.

"Не просто просто" противоречит с "простой не только сложный, но еще и кривой" в моей реплике на предыдущей странице. Да, есть такое. Гриппую-депрессую.

Уметь только асм - недостаточно. На асм не увидишь логики программы, утонешь в реализации мелочей.

 

Играюсь с файлом mp4... Но... Как только разобрался с stsz и смог находить их в mdat, тут же приходит мысль - ну а если убились правильные смещения - что ж я сам их не расчитаю??? Да не***ер делать...! Потом нашёл все чанки и их смещения... Если просто по данным этих атомов восстановить или пересобрать файл.. - то это и дурочка сделает.... и всегда вопрос! А если их нет или они не верны - что я сам не расчитаю???!!! Да делать не***й!!! И опять новый поток неисчерпаемых мыслей... Потом приходит мысль - да пусть атома moov вообще нет... А только mdat.. Что я не восстановлю что ли??? Да делать не****! Потом далее - в самом mdat указаны смещения.... - и сразу мысль!!!!! да по ним и дурочка всё восстановит... А если они неправильные и их нет??? Сможешь??? Да делать не***!!! Тогда уже начинаем вообще всё по другому... ищем 658884... посредством and... потом ищем 77 ?? 9? 41 .... тем же макаром.... и считаем считаем и считаем.... и эт я ещё не находил звук - только видео.... потом опорные кадры поискать надо... и всё предполагается что сплошной массив без единого маркера .... Вот такие задачи себе ставим... Отсюда и вопросы..........