flat assembler
Message board for the users of flat assembler.

Index > Tutorials and Examples > Video Tutorial/Demonstration

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
m3ntal



Joined: 08 Dec 2013
Posts: 296
m3ntal 12 May 2014, 09:19
2 example videos. Teaches how to create variables, loops, etc. Used EZVid for video capture, VideoStudio for editing and Z-IDE to write code. Hope this inspires users to create videos.

Z Tutorial. New!
Z-IDE Preview (LQ)
Post 12 May 2014, 09:19
View user's profile Send private message Reply with quote
zhak



Joined: 12 Apr 2005
Posts: 501
Location: Belarus
zhak 12 May 2014, 09:55
1. too much screen zooming.
2. are you reinventing C?
Post 12 May 2014, 09:55
View user's profile Send private message Reply with quote
m3ntal



Joined: 08 Dec 2013
Posts: 296
m3ntal 12 May 2014, 16:34
1. I'd love to see you do better
2. This language is 100% FASM. It has little in common with C which you obviously don't know.
Post 12 May 2014, 16:34
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 12 May 2014, 17:23
m3ntal wrote:
2. This language is 100% FASM.

Indeed, it is 100% FASM, but 0% assembly. Twisted Evil

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 12 May 2014, 17:23
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
m3ntal



Joined: 08 Dec 2013
Posts: 296
m3ntal 12 May 2014, 19:17
Please compare my macros to others written in FASM (invoke, stdcall, struct, etc) or to FASM libraries (FreshLib, FASMLib) or to low-level languages like HLA, RosASM, C--. Note: LL compiler = HL assembler, same thing. It is unfair to compare this macro language to existing languages when it has the restrictions of FASM and the advantages. Unlike all other languages, this is 100% FASM assembler in addition to the macro syntaxes and it can generate code for anything. How am I "re-inventing" when no one else has made a (good) macro language in FASM?

Low-level or high-level? How do you (users) determine what is LL or HL? Just take one glance then make a stupid judgement based on the syntax, how it appears, without knowing anything about the language or the internals. When I say LL, I'm referring to how close it is to the CPU/machine, not how easy the syntax is. By this definition, Z is the lowest level compiler I've seen.
Post 12 May 2014, 19:17
View user's profile Send private message Reply with quote
m3ntal



Joined: 08 Dec 2013
Posts: 296
m3ntal 12 May 2014, 19:18
John: You don't know shit about my language or library. Z is 90%+ CPU usage, therefore, much lower level than FreshLib. You write HL macros, stdcall, var (JavaScript), body (HTML), they're just not good ones. Your idea of "assembler" is this:
Code:
stdcall OSDoItForMe    
Post 12 May 2014, 19:18
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 12 May 2014, 19:25
"var" is from Pascal. Razz
Post 12 May 2014, 19:25
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
zhak



Joined: 12 Apr 2005
Posts: 501
Location: Belarus
zhak 12 May 2014, 19:45
m3ntal, no need to get mad. You put a great effort in this project, it can be seen with an unarmed eye. From the perspective of how you wrapped all the stuff in macroses it is very cool. But what John said about 0% assembly I think it's about wrapping the hole thing with a macro-blanket. It's like you've created a HLL based on asm. Personally I wouldn't like to see 90% macrocode in my source, where I just put if-then-else, call to super-macro-stdcall-wrapper and the rest, when registers and all other things are controlled by pre-defined macroinstructions rather than giving a developer an option to choose. like I wanna use edx in a loop instead of ecx and cmp ebx, smth. in if-then-else block instead of what is defined to be used in macro. As in all HLL you achieve simplicity, but you lose control
Post 12 May 2014, 19:45
View user's profile Send private message Reply with quote
m3ntal



Joined: 08 Dec 2013
Posts: 296
m3ntal 12 May 2014, 23:52
User opinions are from those who do not know the language, the internal operations it performs and how it corresponds directly to instructions, allows custom code generation, and the fact that it is 100% assembler in addition to what you see.

You don't owe me an explanation for not using this since I have never recommended my language to anyone. I don't want anyone to "use my language". I want them to improve it, but I think Tomasz is the only one who can.

Hope this motivates users to create videos, tutorials, show their programs.


Last edited by m3ntal on 17 May 2014, 02:17; edited 1 time in total
Post 12 May 2014, 23:52
View user's profile Send private message Reply with quote
m3ntal



Joined: 08 Dec 2013
Posts: 296
m3ntal 15 May 2014, 12:32
My code is NOT intended for you so I shouldn't feel obligated to explain myself...
Quote:
As in all HLL you achieve simplicity, but you lose control
Wrong! Does invoke prevent you from using push-call? Does the existence of a proc macro prevent you from ever writing a procedure manually? You don't know what you're talking about.


Last edited by m3ntal on 18 May 2014, 21:48; edited 2 times in total
Post 15 May 2014, 12:32
View user's profile Send private message Reply with quote
sid123



Joined: 30 Jul 2013
Posts: 339
Location: Asia, Singapore
sid123 15 May 2014, 13:53
No offence but a dialogue from Grand Theft Auto:
Quote:
....And there we go again......

As for the library it's looks good from a first glance, I do have some complains about the look of the IDE, I personally am a fan of "flat" interfaces (checkout the Visual Studio 2013 look). That's my preference though.
Quote:
As in all HLL you achieve simplicity, but you lose control

I know I'll get flamed for this, but sadly the truth is you lose maintainability and audience when you code in assembly. Using "macros" and the power of the preprocessor makes the situation a little better.
And yeah, why so angry? Don't take any offence but have you had your coffee today? Razz
Post 15 May 2014, 13:53
View user's profile Send private message Reply with quote
m3ntal



Joined: 08 Dec 2013
Posts: 296
m3ntal 17 May 2014, 07:57
REAL ASSEMBLER?!

JohnFound wrote:
Quote:
Fresh is only asm. Write some valuable asembly code and I will ask you as well to use your code.
1. FreshLib HL syntaxes are NOT "real" assembler - var, body, invoke, stdcall, proc - and NOT good HL either.

2. Z produces superior optimizations, much smaller, way faster and more effecient than FreshLib. I can prove it with disassembly and comparisons (on Android now). Or see for yourself.

3. Assembler is supposed to be about programming the CPU. FreshLib makes all calls to the highest level OS-specific functions written in C/C++ and VB. "Smart" programmers do the opposite: Use HL syntax (macro/C/script) to call LL functions written in assembler, engine "under the hood".

4. John judges by appearances and words: As long as it looks like assembler, it is. So, if you rename function to proc, then all of the sudden, it becomes LL (there is a post where John argues proc=LL, function=HL). Likewise, if you write this in Javascript - function add(a,b) { a+=b } var eax=0, ecx=1, etc - it is assembler according to John. And if you rename struct to class, it instantly becomes HL and object oriented.

sid123: No offense taken. I agree with the statement about ASM. See .3.


Last edited by m3ntal on 18 May 2014, 22:51; edited 1 time in total
Post 17 May 2014, 07:57
View user's profile Send private message Reply with quote
m3ntal



Joined: 08 Dec 2013
Posts: 296
m3ntal 18 May 2014, 21:54
What Z Needs:

* Type safety, error checking
* Select un/signed arithmetic: <<, >>, *, /, <, >. No separate symbols or "(signed)" prefix
* Pointer arithmetic: . (u8) *a++=*b++. Written but untested
* Arrays, structures: . images[i]->x=0. Written but untested
* Local arrays and structures
* Remove [] from integral types. Arrays *and* objects/structures are accessed by reference. Indices and members are accessed depending on their type
* Expression parser
* Relational "and, or" for if/while/for: if a=1 and (b=2 or c=3)

John: My suggestion to you: Replace all appearances of stdcall/invoke/cinvoke/etc with one smart call macro that works for all conventions. call is a real instruction, it would avoid having to use 3+ separate keywords (why?!), save source space, portable convention. FL would be much cleaner if you replace all stdcall/invoke/cinvoke/etc with this:
Code:
call f, a, b, c    
Post 18 May 2014, 21:54
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 19 May 2014, 04:34
Quote:
Replace all appearances of stdcall/invoke/cinvoke/etc with one smart call macro that works for all conventions.

The code should be readable and unambiguous. Using different names allows the programmer to always distinct the cases reading the code. For the same reason, FreshLib uses macro "return", instead of redefining "ret" instruction for returning from procedure.
Post 19 May 2014, 04:34
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
m3ntal



Joined: 08 Dec 2013
Posts: 296
m3ntal 19 May 2014, 06:18
Quote:
Using different names allows the programmer to always distinct the cases reading the code
There is NO reason to use different names - fastcall, stdcall, invoke, cinvoke, etc - NO reason to re-specify the convention in the call everytime. A much smarter way is to create one good call macro with parameters that supports all conventions. The proc/import macros only need to define a .type constant: type='f' (fastcall), type='s' (stdcall), type='i' (invoke), type='c' (cinvoke), type='a' (ARM APS call). Windows users could go back to using: call f, a, b, c
Quote:
For the same reason, FreshLib uses macro "return"...
... which still can't specify a value for the accumulator. No more useful than ret. If you're going to create a HL return, do it right.

Typed on Android Jota Text Editor. Works good!
Post 19 May 2014, 06:18
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 19 May 2014, 08:01
m3ntal, read again my post and think a little.
Post 19 May 2014, 08:01
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
m3ntal



Joined: 08 Dec 2013
Posts: 296
m3ntal 19 May 2014, 09:00
Reasons why call with parameters is best: It is a real instruction, works for all conventions, avoids having to use 5+ separate keywords (why?!), save source space, etc.

Reasons to use fastcall/stdcall/invoke/cinvoke/apscall/etc? NONE! Reasons to RE-specify the convention every time? NONE! Reasons to NOT use call? NONE! The only reason one could have is laziness: "I don't have enough time, care and/or knowledge to write one call macro that does it all. And I don't want to have to edit my library".
Post 19 May 2014, 09:00
View user's profile Send private message Reply with quote
m3ntal



Joined: 08 Dec 2013
Posts: 296
m3ntal 19 May 2014, 09:26
Quote:
read again my post and think a little
Details of calling convention are unimportant when writing code and you will know by the system. Example:
Code:
call MessageBoxA, 0, eax, eax, 0    
Post 19 May 2014, 09:26
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20356
Location: In your JS exploiting you and your system
revolution 19 May 2014, 09:27
m3ntal wrote:
... call with parameters ... It is a real instruction
But if you make "call" a macro then it is no longer a "real" instruction. You also lose the ability to read the Intel/AMD manual and determine what call does. I have always liked the idea of separating the macro names from the instruction names, mostly to avoid confusion about what is actually being done. Overriding call as both an instruction and a macro increases cognitive load for the programmer. We are not all as young and smart as we would like to be and anything that eases the brain loading is welcome.

BTW: ARM does not have a "call" instruction. So on that CPU "call" would be fine because it does not clash with anything predefined, and it is clear that to find out what "call" does one must find the macro definition(s) in the source.
Post 19 May 2014, 09:27
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20356
Location: In your JS exploiting you and your system
revolution 19 May 2014, 09:36
m3ntal wrote:
Details of calling convention are unimportant when writing code and you will know by the system. Example:
Code:
call MessageBoxA, 0, eax, eax, 0    
Here my opinion differs because in some conventions (IIRC Pascal) the parameters are pushed left-to-right and other conventions (stdcall) they are pushed right-to-left. This is important to know because such things like the following are affected:
Code:
call function,edx,addr buffer    
In an L2R convention this works as expected but in R2L this fails because the value in edx is corrupted before it is pushed. Whereas if we had, say, pcall and stdcall then it would be clear to us that we had to write the parameters differently.
Post 19 May 2014, 09:36
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.