Hmmmm....., I guess I'll have to take your word on that.



It's all relative. Compare him to Tomasz who gives and gives and gives and never criticises anyone for anything, who tries to help all endeavours no matter if it's perceived by other as pointless, f0dder's attitude sucks big time

We could all use more Tomasz's in this world, but I also see value in the dissenting voice [1]. Sadly, one could argue Tomasz is the dessenting voice (I would join him in the minority if that were the case).

It's definitely worth optimizing, but I believe it's still at a point where focus should be on algorithmic improvements (and the source layout/structure - it's currently pretty ugly). Still, it would definitely pay off to put on the optimization goggles and give the code a good reivew... and writing assembly alternatives to some parts is probably a good idea as well.

But the idea of rewriting the entire thing in fasm is pretty silly, imho. It would mean less people were able to contribute (face it, there aren't as many assembly programmers), and there's large parts of the 7-zip project that wouldn't benefit from it anyway (UI, file handling, ...)

I still do kinda like x86, after all it's what I grew up with - but I think it's a messy patchwork and that we could have much a more comfortable architecture (better for compilers as well as more fun to hand-code) if things had gone differently. I still do assembly now and then (not least because of intel's VMX instruction set), and I advocate using it where it make sense but not otherwise... and I guess that makes me come off as anti-assembly to some people

And this is what really stumps me about your negative attitude. What do you fear from assembler, it's never going to over take the world. There are scant resources devoted to it, yet you feel the need to criticise it when ever you can??????

I hope this project takes off as the f0dders at this forum have been so negative towards assembler, if they took a break and looked around, they'll find there is sweet f all projects of any type going on and there battle to defeat the evil assembler has been won, YIPPEE


Casm (my fasm stripped assembler) is less than 50k. Compressed with 7zip, it's 20k. This is quite cool as not only does it assemble it's self, it can assemble and run small OS's (the future of computing, not bloated hll OS's we currently have), windows progams of all kind, com, win32/64, linux programs of all kind. It can be assembled in less than a blink of the eye so it is optimises for the platform it runs on (well one day that's the plan) .... yet I come here, and see nothing but negativity from people like you about assembler and I wonder why?????


I just want a LZMA include for casm so I can compress/uncompress it's output. If written in fasm syntax, please who ever does it, avoid macros, you'll be surprised what you can achieve with a editor using copy and paste.

MHajduk, нет. Я работал по своим делам с LZW (для GIF) - пришла идея о LZMA. Своих наработок пока нету. Если никто здесь не сможет выложить/сделать - буду делать сам. (Просто пока времени нету - дипломирование ))))

everybody:

the only, and only one problem with assembly is the differences between syntaxes. as well as inside the x86 assemblers and in other architectures assemblers.

there are a lot of assembly coders, some prefer Masm, nasm, fasm, tasm, yasm, gasm, GCC, etc..
some others code for various architectures like PIC, DSP, Motorola, and all theses archs have many different assemblers too...

then, instead to rewrite and reinvent new syntaxes, one usefull job would be to unify all differents assemblers and architectures that they can be coded for any assemblers.

just look at C like syntax.
whatever is the compiler, the syntax is always the same. a C code writen for Borland C or GCC will be compiled with any C compiler.

fasm syntax is powerfull.
all can be made by the simple CALL instruction.
just need the unified librairies. thats all. and then, everything can be made in asm using the simple and powerfull fasm syntax.

if one day i write an assembler, it will be with the exact syntax as fasm. and as i'm french, it will be named frasm. and as fasm still exists, i don't see why i would write a new one. just i'll adapt fasm to my future OS, or adapt my future OS to existing fasm.


code unification.

edfed: If you take a look at some other processor you will see why your suggestion can't work. The CPUs are fundamentally different. If you create some sort of "unified code" I would expect it to start looking like an HLL.

narada
А... теперь понятно. Кажется, что действительно тебе надо будет портировать LZMA на ФАСМ самому, но думаю, что стоит и можешь быть уверен в успехе твоей программы. Желаю удачи. Если не секрет - интересно, какая тема дипломной работы?

MHajduk - диплом один на 10 человек, мой раздел - криптографические ключи (в частности алгоритм хэширования PJW-32)

edfed^
Just for me assembler is more clear and is logical, than C++. For me at least. And on with you will not consider such 70% of nuances which can be used with asm. Imho.

The main problem is that running ASSEMBLED code sucks...

Does anybody know a good assembler INTERPRETOR ? just interpreting the lines like "mov ax,bx", etc... ?? so we can start easily programs with 4000 or 5000 lines of assembler? I got exhausted with all those small ASM programs with 50 lines, compiled and then run as a .COM file...

thats's why too many macros makes the code hard to be run with an ASM interpretor, thats's why MASM is totally out of date for ever, because too many macros for an ASM interpretor.

yes, i know, and that's why it need unification.
i learnt ASM on various non x86 platforms. 6809 (the asm revelation), 68HC11, 68HC16, PIC 16F84, 80C52, 80C51, TTL & CMOS LOGIC, Analog electronics. yes digital & analog electronics are assembler too in the way it's full of optimisations tricks and assembles components instead of instructions. never learnt FPGA cause µP are better. i'm not so dumb and young you know!
X86 is my favourite assembler. powerfull, cheap, international, it is the more spoken language of the world. even a C compiler speak X86 asm. 99% of the machines on the planet speak X86. and i hopen it wil be 100% one day. i'm not for the supremacy of intel, X86 shall become a norm, a specificcation to follow and respect when building new µP.

Bad idea, you end up with either a lowest-common-denominator, or some overcomplex abomination... if you wanted a "generic assembly language", you're better off coding in C instead - assembly is suposed to be WYCIWYG, machine-tailored.

Same-ish syntax across different platforms could be a decent enough thing, but there you already have GAS

Okay, but from what you are posting it seems like you are not aware of the varied architectures. Perhaps you can outline/example/illustrate what you are intending, perhaps I have the wrong idea about what you mean.

i think we just have to wait for unification. it will be done one day. it cannot be ignored from the biznessmens as it will permitt them to make more and more money for sure.

in the global idea, all future µP shall share the same basis, they still have all the same gobal architecture in the mean they have an ALU, buses and instruction decoder based on transistors. then, we can assume they are all the same, but with different opcodes. the opcodes are not the syntax, then, a good old 68k from the megadrive (big endian) can be coded with the exact syntax as the one in fasm, with eax, ebx, ecx, edx X86 registers naming and add, imul, shl instructions names etc.
only the parser will assemble the instructions in the MC68k form with an option in command line. fasm file.asm file.exe for X86 and fasm file.asm file.bin -68k for 68k extension.

it is the first step to unification of informatics. making all assemblers with the same and exact syntax. it will be to the programmer to say what is the target machine, and knowing that, take the limitations of the target in mind while coding.

the second step is to have all µP with the same opcodes. and then, no matter of the target because it will be the same binary for all µP, just the limitations of the various families will induce differences.

the third step is to have all µP with the exact same architecture. the same register sets, with some extensions for particular purposes as integrated DSP, Crypter, GPU etc...

if this is never done, it simply means the computer world is only money and cannot be helpfull to humanity.

step 0 is to force the proprietary companies to stop producing and inventing bad designs, just to justify the presence of ingineers. intel is the more advanced company in electronics of the world. they are the best, just the fact they can produce 25nm low consumption and fast µP is a proof of their talents.

M$ and ibm made too much money on the back of their clients to give what? just code. intel does the same, but they give us hardware.

please note that to make the so wanted AI, all µP on the network shall speak the same langage to be able to think. exactlly as our neurons speaks the same langage in our heads.

but who am i to predict such a things, it's not predictions, but more hopes, cause hte first think i saw in learning assembly was this problem, the differences between architectures, inducing the creation of "HLL". but asm is really able to HLL without any extra layer. CALL is the meta instructin, able to execute from the simpler to the more complex function or program. then, just can you imagine a sort of network based all on the same architecture, transmitting not ascii chars or things like that, but more assembled instructions that can be directlly executed.
take the control of a distant machine by opening a CS canal. some big problems should be the security, but i learnt one day that the µP destined for the communication shall be different of the target µP, to have a secure connection. it is a principle still used in the company where i worked in the past, one DSP for the communicatin, encryption, decryption, and the main µP with integrated DSP for direct code execution. this is very powerfull and reliable as the network frames will be threaded transparentlly and the target never see any data other than what it should use. and it free an irq because for network, we need to analyse the flow constantlly to know if we are concerned.

I have just spent this whole day doing ARM programming. Whenever I switch to ARM from x86 I have to change my way of thinking. I don't see how it is possible to unify those two and still get a good result. I think you would need some sort of translator and an intermediate code format and then translate it to cater for the two architectures, oops, looks like I just described an HLL.

I think your step one and step two are in the wrong order. Plus for your step two the happen, by default, step three will also have happened as part of step two. So, it comes down to this 1) all CPUs become the same architecture, 2) all assembler syntax is the same.

If the whole CPU world moves to only one architecture (maybe the ATOM will help to make this happen?) then, and only then, can the assemblers be the same.

But even so, I think there are just too many applications of varied demands and one CPU architecture cannot be suitable for them all.

Hmm, back to compression.... After my current project I will be planning a FASM macro compressor & a library if I have any supporters .

I am curious about what you mean by this?

i think he wants a macro to compress the compiled binary from a desired offest to an other offset.
the start shall be uncompressed and must contain the decompressor and jmp to decompressed binary.

is it possible?

assuming the macro mechanism is a script language and can be concidered as a HLL.