flat assembler
Message board for the users of flat assembler.

Index > Heap > Ultimate Dream Language

Thread Post new topic Reply to topic

Joined: 17 Jan 2012
Posts: 369
In this post, I'd like to present what I believe to be the best macro language ever designed in the history of mankind. Implementation is unfinished (about 90%).

Future Macro Language (FML)
! rgb(byte r, g, b) - color 
 . r1=r, r2=g, r1<<16, r2<<8, r1|r2, r1|b, end! 

! strlen(string s) 
 . r1=s, while *s, s++, endw, s-r1, s--, end! s 

! strcpy(string a, b) 
 . while *b, *a++=*b++, endw, *a=0, end! a 

! strcat(string a, b) 
 . strlen(a), r1+a, strcpy(r1, b), end!

! strcmp(string a, b) 
 . while *a=*b and *a|*b, a++, b++, endw,\ 
 r1=*a, r1-*b, end! 

! strchr(string s, char c) 
 . while *s, ? *s=c : return s, s++, endw, end! 0 

macro strequ a, b { . strcmp(a, b), ~r1 } 

! memcpyb(void *a, *b, u32 n) 
 . repeat n, (u8) *a++=*b++, endr, end! 

! memsetb(void *p, byte v, u32 n) 
 . repeat n, (u8) *p++=v, endr, end!

; optional function/endf keywords
; (for IDEs with syntax coloring).
; all statements may be written on
; individual lines...

function rgb(byte r, g, b) - color 
 . r1=r, r2=g, r1<<16, r2<<8, r1|r2, r1|b

function strlen(string s) 
 . r1=s
 . while *s, s++, endw
 . s-r1, s--
endf s

function strcpy(string a, b) 
 . while *b, *a++=*b++, endw
 . *a=0
endf a

function strcmp(string a, b) 
 . while *a=*b and *a|*b
  . a++, b++
 . endw
 . r1=*a, r1-*b
* Easiest, most compact language in existence. Destroys C/C++/C#/Java. In one line, FML can do what would take an average HL programmer 10-30+ lines.

* 100% FASM macros. Not another frontend or separate compiler/assembler like C--/HLA/RosASM

* 100% machine code. Not another useless interpreter

* Universal portability: X86+ARM (someday, JVM and MIPS). 100% customizable for any CPU/OS

* Easy translation to/from C/C++/HLLs, even FASM's own preprocessor language. Anything that we can do with FASM's assembly-time "if/while/etc" can be converted to runtime code and vice-versa.

* Maximum production speed. For creating real-life applications in a professional workplace

* Direct memory access for LL/systems/bare-metal programming. C-style &address/*value syntax. No cryptic conversions: *(unsigned*) p=n. Just the size: (u32) *p=n

* Strict types/sizes safety: i8/u8/i16/u16/i32/u32/etc. Solves the problem of naming and using vague words ("w/ord/h/alf"): i8/i16/i32/etc are the real names and "integer/string/void/word/half/etc" are just aliases whose sizes are not guaranteed.

* Invaluable educational utility for teaching beginners the essential concepts of programming - variables, if, loops, functions, pointers, etc - and it can help ASM programmers understand what HL syntaxes convert to and how to optimize them.

I challenge anyone to improve the syntax/semantics of this language. Please show me a better way to express common functions (strlen, strcpy, etc) that can be implemented in FASM.

Fact: A+B requires less energy than A=A+B.
Post 16 Jul 2013, 08:06
View user's profile Send private message Reply with quote

Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
Let me give some constructive arguments against this:

* Language source code doesn't look very maintainable: in today's world where everything requires money you want to save every bit of programmer's time possible.

* We have ASM to fill the low level gap and C for medium level. C++ for OO while still maintain access to C and ASM.

I think every kind of language has already been invented. It's just a matter of using the right tool for the job.

It will be very educational if you build this language tough. It may or may not be revolutionary, I don't know.

I was once a diehard ASM fanatic. But our perspectives change.
Post 22 Jul 2013, 21:26
View user's profile Send private message Reply with quote

Joined: 17 Jan 2012
Posts: 369
Let me give some constructive arguments against this:
Thanks for responding, but you did not give any reasons. Only kind of "criticism" I receive from this community is baseless opinions, ungrounded statements: "not real", "bullshit", "so-and-so is not a real Christian". No logic, no reasons, no facts based on numbers. I wish they (John & Guru specifically) would learn what my macros+syntaxes do before making foolish judgments about things they don't understand. Sorry, I do not respect their opinions that are based on ignorance, what a person does not know.

First, I failed to mention that this language allows 100% ASM (Intel+ARM) to be written anywhere so it's an addition to the power of ASM (does not take away from it). You can even access general registers in the HL syntax (all but the last 3): In I32, r1-r3 = eax/ecx/edx (edi=destiny, esi=source, ebx/bx/bh/bl=calculations). In ARM, you get r1-r10 = r0-r9/a1-a4+v1-v6 (r12=destiny, r11/v8=source, r10/v7=calculations).

Second, there are 3 alternate styles, naming preferences and conventions that all follow the same underlining syntax/semantics: strcpy, string.copy, String.Copy. Programmers have the choice which style to use.
; ultra-compact lowercase...

! strcpy(string a, b)  
 . while *b, *a++=*b++, endw, *a=0, end! a

; expanded Proper.Case...

Function String.Copy(String A, B) 
 While *B
  . *A++=*B++
 . *A=0
EndF A    

You can also write code in plain English. (strcpy/memcpy/etc are special functions involving memory access (*p/*p++) and they should be compared to the equivalent in C/Pascal, not to something else written in VB). () is optional for functions/calls.
Function Test(String File, Pointer Data, UInteger Size)
 Pointer P
 Try Create File
 Write Data, Size
 Open File
 Try P=Allocate(Size)
 Read P, Size
 Execute File
 String.Reverse P
 Say P
 String.Copy Buffer, P
 Destroy P
EndF 1    
Please compare this language to C/C++:
// C/C++...

unsigned rgb24(unsigned char r, unsigned char g, unsigned char b) {
 unsigned r1=r<<16, r2=g<<8;
 return r1|r2|b;

; FML...

! rgb24(byte r, g, b)
 . r1=r<<16, r2=g<<8, r1|r2, r1|b, end!    

FML is mainly for LL/systems/bare-metal ARM programmers. My latest ARM code has improved "standard" compatibility. Removed pseudo-instructions, HL macros (movi/dec/jmp/etc) that imitate X86, this was only temporary to get things working. ARM should not be modeled after X86. It would not utilize ARM's capabilities, it would be horribly inefficient (possibly 3-4+ times as much code) and definitely not "real ASM" on ARM. FML is the solution.

(PS: My Zymic web host is down again so none of my site images are visible and none of the downloads are active. Wait about 3 days)

Last edited by uart777 on 23 Jul 2013, 10:24; edited 1 time in total
Post 23 Jul 2013, 06:35
View user's profile Send private message Reply with quote

Joined: 17 Jan 2012
Posts: 369
Standard Window example:
; Future Macro Language

include 'windows.h' ; Style=C

char *title='My Window'

int screen_w, screen_h

HWND window
MSG msg
HDC hdc


;;;;;;;;;;;;;;;;;;;; WINMAIN ;;;;;;;;;;;;;;;;;;;;;

function WinMain(HINSTANCE hi, HINSTANCE hpi,\
 char *commands, int show)
. wc.cbSize=48
. wc.style=0
. wc.lpfnWndProc=!WndProc
. wc.lpszClassName='WC'
. wc.hInstance=hi
. wc.hIcon=LoadIcon(0, IDI_APPLICATION)
. wc.hCursor=LoadCursor(0, IDC_ARROW)
. wc.hbrBackground=GetStockObject(WHITE_BRUSH)
. screen_w=GetSystemMetrics(SM_CXSCREEN)
. screen_h=GetSystemMetrics(SM_CYSCREEN)
. RegisterClassEx(wc)
. window=CreateWindowEx(0, cname, title,\
 WS_STYLE, 0, 0, screen_w, screen_h,\
 0, 0, hi, 0)

;;;;;;;;;;;;;;;;;; MESSAGE LOOP ;;;;;;;;;;;;;;;;;;

  .if not GetMessage(msg, 0, 0, 0)
    goto .r
endf msg.wParam

;;;;;;;;;;;;;;;; WINDOW PROCEDURE ;;;;;;;;;;;;;;;;

function WndProc(HWND w, int message,\

.if message=WM_PAINT
 . hdc=GetDC(w)
  ; ...
  ReleaseDC(w, hdc)
 return 1

.else.if message=WM_KEYDOWN
  .if wp=VK_ESCAPE
    goto .x

.else.if message=WM_CLOSE
  .x: PostQuitMessage(0)
  return 1
endf DefWindowProc(w, message, wp, lp)    
Post 23 Jul 2013, 09:08
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  

< 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 can attach files in this forum
You can download files in this forum

Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.