Assembly Macros? Could they be used to make a new language?
Could assembly Macros be used to make a full fledged language? FASM has some fairly powerful macro potential, which interests me, but I only know the basics of ASM. TonyMac was working on creating a slew of Macros to help with dexOS coding, I believe? Anyone know how far he got with that? Does anyone know if it would be possible to create a true(fake) high level language using just macros, or would a new compiler have to be built? A while back some of you were talking about JIT compilers, and cogs/wheels, and stuff like that. I gather you were talking about creating a new simplified language with JIT compilers on every CPU architecture, and similar backend mechanics to java? Would this language aimed at dexOS, or other platforms too? And would it have similar capabilities to FASM macros, or go far above and beyond them? I'm tossing ideas around in my head, so any answers would be great. :D

yes, that was the intent. I'm working on a simple basic-like syntax for DexOS FASM right now, so I get back into programming. And now that you mention it, it could theoretically be possible to create a nearly identical basic-like syntax work on all the machines... assuming they have a compiler/assembler that compares with FASM. As far as my status goes, I have a few simple things working to mask the user from some of the scarier parts of setting up a DexOS app, and am beginning to implement more functions. I'm afraid to actually get something that could be deemed a seperate language a front-end arer would have to be used to keep track of memory/variables/etc, things that migt be reserved in FASM and hard to work with. I will keep you posted on my progress. I unfortunately somehow destroyed my Propeller processor from Parallax during a hardware change. I'm going to get another one, but right now I'm working on PIC projects and DexOS.

Neat stuff. :) I've done a lot of web scripting. For years now I've created HTML apps to do various tasks(ex: reformatting data). Recently I got interested in image formats. I built one in Javascript...but it's so horribly slow, that I determined I must learn other languages if I wanted to continue developing it. So I learned Java, and after a few small projects(pipe dream, etc.) that leads me to today. Somewhere inbetween I worked on string and number manipulation. I built a parser that understands javascript syntax, and...does nothing with it. It just understands the syntax. It was quite fun(and easy) to make, though. I also built a bunch of java objects. One I call the DepthGrid, as it lets you pack ints into N bits. So for example, if you had an image with 49 colours, then there's no reason to store more than 6 bits per pixel is there? Just index the colours, and store the colour ID in as few bits as possible. ;) Then I optimized it into new BoolGrid, TwoBitGrid, FourBitGrid, DepthGrid, and BitArray objects, which all have slightly varying tasks. Coding those really hightened my appreciation for ^ & | >> << :D Anyway, despite all this semi-low-level stuff, I still find myself preferring javascript syntax to java syntax. It's just more friendly... Which is part of the reason I brought this up. You think a BASIC-style language would be possible with macros...but do you have any desire to go beyond that?

Well, I'm planning to take it one step at a time. I miss the good old days of Qbasic where an app for a simple non-cpu intensive task could be written and compiled ina few hours and not require all the clutter and complication of a GUI. Dex and I have actually talked over the possibility of going a step further, after I am sufficiently satisfied with the BASIC setup. If your parser could understand the Javascript, you should be able to easily make a front end for FASM that translates the language into assembly and assembles it, all depending on how far you want to go with it.

I for one can see know reason why you should not be able to make a basic type language from fasms macro's. But only by coding it and fixing any problems you come up with, can you be sure, if it will works. So far we know this would work in a dos environment macro PRINT String{ local .Printer local .Nextchar local .Done local .a .Printer: mov si, .a mov ah, 0Eh jmp .Nextchar .Nextchar: lodsb or al, al jz .Done int 10h jmp .Nextchar jmp .Done .a db String,10,13,0 .Done: } macro SCREEN mode { push ax if mode = 0 mov ah,0h ;SCREEN 0; Default DOS screen mode mov al,3h int 10h else if mode = 13 mov ah,0h ;SCREEN 13; VGA mov al,13h int 10h end if pop ax } macro SLEEP { ;Output: ;ah = BIOS scancode of key pressed ;al = ASCII character of key pressed ;Could have also used... ; mov ah,8h ; int 21h mov ah,0h int 16h } macro END { mov ax,4Ch ;\END int 21h ;/ } macro LOCATE row,col { pusha mov ah,2 ;Function 2 mov bh,0 ;Use page 0 mov dh,row ;row mov dl,col ;col int 10h popa } And then you can do this: SCREEN 0 LOCATE 5,5 PRINT "Hello World" SLEEP END Doing a DexOS ones will be just as simple, as tonyMac as shown, the main problem is people may not think of it as a language, also the size of the exe compared to asm code, eg: proc jump to the code and back, macro put the code at the place you call it from, so if you call a proc 20 time its not 20 time the size of the proc, but if you call a macro 20 times it would make it 20 time the size of the macro, as macros are just placed at assembly time where they were called from. But still it would be small compared to normal basic. Also it would be very easy to add inline asm :lol: . regards Dex.

@Dex: In a lot of cases your statement about procs would be true, however I've set up "sub" and "function" as macros that create call/return blocks, so that if you define a function or a subroutine it will call it and return. I will get more work done on this soon, I'm working 10 hour days at the moment to catch up before I head back to class.

Agreed. The macro language of FASM is extremely powerful, I don't really even begin to scratch the surface of it. The only possible limitation wil be the number of passes the assembler will make before failing the code. especially in something like a java-based system, calls making calls to other functions that in turn are based upon something else will be to the very limit of what the assembler is going to be willing to deal with. On the other hand, if a universal high-level assembly language bytecode was worked out, a javascript compiler could produce that code, then that code's compiler could produce the FASM executable. An added feature would be possible cross-platform use of your javascript-based language. I'll keep working on BASIC, and we'll see how everything meshes together and apply that to Jscript, obviously with a lot of help from you. Pseudocode of what all the functions do at the lowest level you can think of would be greatly helpful for that. On looking at Javascript, it appears to be fairly procedural, am I correct? in that case, some of the code from BASIC can probably be re-used to create Jscript, and possibly a sort of C.

Yes, javascript is quite procedural; but it's always described as an OOP language. Objects are a big part of designing efficient JS apps. One of the things I like about it, is it isn't strict with types of variables. For example, you can have function... function Add(iNumA, iNumB) { return iNumA+iNumB; } If you pass it a string and a number, then browsers will ignore the call as illogical - but if it were converted to assembly, then.. var A = "Hat"; Add(A, 1); Would probably return a pointer to "at". :P Of course, that only works with null terminated strings...but odd things like that are why I love javascript, and why I dislike C. C has about 5 types of variables for every need, and they're usually identical, and you have to typecast between them. unsigned int, UINT, int, etc.; java/javascript one-up C there! One thing I like about C is the # char. The last time I investigated C, macros were difficult to use, and mostly useless. My immediate impression from FASM was the opposite...but I do like that # char. Perhaps # could be used to denote whether you're calling a function, or inlining it? So... var B = Add(1, 2); is a call/return, but.. var C = #Add(1, 2); would actually change to... var C = 1+2; which then becomes... var C = 3; Good idea, or not? It'd allow some control over how strongly code is inlined, I think? And that way the "javascript" -> FASM compiler wouldn't get stumped on recursion, since you just avoid using the # char. :P That'd also work for constants. Ex: You could have... var TileSizeX = 32; But if you always use #TileSizeX, then it changes it to "32" before passing it along to FASM. If you never ever use TileSizeX without a #, then it just removes it from wherever you declared it(to save memory?). Good idea, or not? I'm not sure if that is a good idea, actually. I don't know how constants work. Do compilers(C or other) store the constant once and have lots of pointers to it, or do they leave the value of the constant all over the place? That's the kind of thing I need to know before I can start coding... Anyway, Javascript is designed around having less keywords than other languages; ex: a function can be a function, struct, or class. A var could be an int, float, or a pointer. It makes it easier to learn, which is a plus - especially if it could be compiled to run efficiently.

Another thing I wouldn't mind in such a language...ellipsis. I'm flipping to java syntax for this example. :P This is a mixture of(I believe?) Python, java, and javascript. The best from each? ;) #function Concatenate(String... Strs) { int iLen = 0; foreach(Strs) iLen += sStrings.length(); byte[] newStr = new byte[iLen]; foreach(Strs) // somehow copy the strings to the new byte array return newStr; } Restricted to always be interpretted before the code is passed to FASM. Based on how many strings you pass to it, it changes the code it writes. That's what I'd deem a "pretty powerful" macro. Certainly more useful than the macros I remember from C. Interestingly enough, Java doesn't have such script/code preprocessing, which is a major source of bottlenecks when dealing with Strings. It would convert... String A = "Blah"; String B = "Blah2"; String C = "Blah3"; System.out.println(A+" "+B+" "+C); To something like... void concatenate(String stringA, String stringB) { byte[] newStr = new byte[stringA.length+stringB.length]; //Copy Strings to new buffer. return newStr; } System.out.println(concatenate(concatenate(concatenate(A, " "), B), " "), C); Obviously, that's a lot of recursion and buffercopies when it could be done more efficiently. Java actually has a "StringBuilder" object that you can use if you want to code the same thing manually...but that's restricted to Strings...and if the coder doesn't know about the object, then they get stuck with the stupid way of concatenating. It should be done automatically behind the scenes...

Some forth implementation has a correspondence one to one in words->asm generated.. my languaje has a compiler very simple.... but is very diferent to Javascript :( I can't wait for the next DexOs release !!!

I have some new things completed on the BASIC Macro-language, and am looking at making the data types objects. (.length, .type) to facilitate better handling with typed functions. Currently functional: Locate Color Println Gosub Def Func...End_Func Sub...End_Sub ...In the works: Dim Input string reassigment

Cool, i am working on DexOS virtual floppy, you just change to b: driver and you can read/write like a normal floppy, but it will all be in ram, so you will need to save to real floppy or hdd etc, before leaving DexOS. Its in the form of a driver, so you can chose to load it or not at any time. It speeds assembling in DexOS with fasm, as it very fast, press the <enter> and its assembled 8) .

I just got a GP2X F-200; right now I'm working on a TD in java, which I'll probably try to port to it before continuing with other projects. I'm also checking out all the tools/games available. :D

@Kramy, Do not forget to try the DexOS port to the gp2x :wink:, not got a F-200 to try it on, only a normal gp2x. I have not worked on the DexOS to gp2x port for some time. You can also debug your Gp2x programs from DexOS on a PC. See here: http://www.dex4u.com/etc/gp2x.jpg PS: But you will need a BOB.