Talking installers, I have one tip: Use Inno Setup (if you don't already do)! ;)
BTW: when can we expect the first releases of HLA 2.0?

Best regards,
Tommy
Posted on 2003-12-05 10:42:15 by Tommy
Don't want to wait for HLA 2.0 ... WOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA !!!
When will I see it ???? :grin:
Posted on 2003-12-06 00:41:53 by dreamweaver
The main prob I don't like in HLA is it's syntax very like Pascal but I never a fan of Pascal.
:)
In regards of Intel syntax and AT&T like syntax ( which use in HLA ) I still recommend Randy put in a option
such as #compile <style>
style =Intel,AT etc ....
or
style = Win , Lin etc ..

which with ex style=Win then program use syntax Intel and style=Lin then program use syntax "mov dest,src" .
It will make all Windows and Linux assembly programmers feel comfortable , I believe .
Why make a macro when you can do it easily and make it an extra feature for HLA ?
Posted on 2003-12-07 09:12:28 by dreamweaver
One problem with this kind of feature is that HLA would lose its standardized syntax.

It would'nt be a problem if your coding only for yourself, but if would definitely be a problem if you have to work with other HLA programmers and everybody is used to their own favorite syntax.
Posted on 2003-12-07 11:27:13 by Kain
Yes, I agree with you about the syntax (dest,src instead of src,dest; else the syntax is excellent! ;) Go Randy! :D)...
Posted on 2003-12-07 11:28:40 by Tommy

One problem with this kind of feature is that HLA would lose its standardized syntax.

It would'nt be a problem if your coding only for yourself, but if would definitely be a problem if you have to work with other HLA programmers and everybody is used to their own favorite syntax.


But in the project people just work on an OS.
In situation of milti-platform , we just break the project to many components and each progrmer must have responsibility on their component.
This feature just effect on mov command , yah .
I refer this feature because HLA is moving so far and now it's not only a learning tool but also an alternative assembly lang for coders. Also in regards of learning tool it will make coders familiar with specific syntax which use in Win or Lin ( I believe in Win they use Intel and in Lin the main is AT&T ) so they can move faster to traditional ASM
But it depend on Randy :)
Posted on 2003-12-07 22:12:35 by dreamweaver
People who know asm already don't like HLA's syntax but those are the people who are not interested in HLA so Randy might not feel that its worth implementing. I think having an option for masm like syntax is not a bad idea though. I guess this would mean that HLA programmers would have to learn two syntaxes. This is not so bad because we still have to learn the syntax for other assemblers like masm to understand code written with them.
Posted on 2003-12-08 01:30:37 by Odyssey

People who know asm already don't like HLA's syntax but those are the people who are not interested in HLA so Randy might not feel that its worth implementing. I think having an option for masm like syntax is not a bad idea though. I guess this would mean that HLA programmers would have to learn two syntaxes. This is not so bad because we still have to learn the syntax for other assemblers like masm to understand code written with them.


You know I brought this up with Randall and I agree with him. Changing the syntax will appease the current assembler users but won't make them consider switching to HLA. It will however break code, require rewrites of his books, and generally cause alot of trouble. If that's the way the syntax is structured, and if it is still useable I can't see a problem with it. To make a switch in the compiler is a bad idea IMHO, it would make two competing and incompatible syntax structures within the same assembler and that would be more confusing to new users than what the current state is. Imagine looking at a code snippet and the author has just C&P'ed the code but not the header file with the syntax directive, you could never be sure what is going on in the snippet. Also copying it to a program that uses the alternate syntax means tracking down each and every changed command and flipping the operands. That is alot of work and can be very confusing when looking at source for a sort algo or any other complicated recursive algoritm. I'm not an HLA user but even I think that it should be left alone at least for the sake of continuity and clarity.
Posted on 2003-12-08 01:47:19 by donkey

Talking installers, I have one tip: Use Inno Setup (if you don't already do)! ;)
BTW: when can we expect the first releases of HLA 2.0?

Best regards,
Tommy


I do use Inno Setup.
Not because it's free, but because it's easy to figure out!
Note: The .iss file for HLA installation is included in the HLA Sources package.

As for HLA v2.0, well, it's going to be a while before the assembler (working) is actually available. I do plan on releasing the source code in stages within the next month or so for a couple of purposes:

1. So people who are interested in playing around with the HLA source code (possibly to help contribute to the project) can begin learning how the system operates while it is still moderately small.

2. So people who want to use some of HLA's algorithms and source code for other assembler/compiler projects can have early access to the code.

The first release of the HLA v2.0 source code will cover declarations, macros, the compile-time language, and stuff like that (basically, everything up to the point of actually handling machine instructions). This will allow people who want to develop assemblers for other processors (or want to develop their own x86 assembler with a different syntax than HLA) to have a big head start on their projects.

Cheers,
Randy Hyde
Posted on 2003-12-08 10:54:16 by rhyde

The main prob I don't like in HLA is it's syntax very like Pascal but I never a fan of Pascal.
:)
In regards of Intel syntax and AT&T like syntax ( which use in HLA ) I still recommend Randy put in a option
such as #compile <style>
style =Intel,AT etc ....
or
style = Win , Lin etc ..

which with ex style=Win then program use syntax Intel and style=Lin then program use syntax "mov dest,src" .
It will make all Windows and Linux assembly programmers feel comfortable , I believe .
Why make a macro when you can do it easily and make it an extra feature for HLA ?


HLA v2.0 will have a new macro facility known as "templates".
Templates will, basically, provide the ability to specify the syntax of a user-defined statement. So if you really want "intel syntax" then you can define templates for the instructions you want and have at it.

Rather than "#compile <style>" all you would need to do is

#include( "intelsyntax.hhf" )

where the "intelsyntax.hhf" file contains the template/macro definitions for the syntax you want. For that matter, one could probably create a NASMsyntax.hhf, GASsyntax.hhf, etc., set of template files. I haven't implemented templates yet in HLA v2.0, so it will be interesting to see how it all pans out. Nevertheless, this is a feature that I've been planning for v2.0 for quite some time.

It's not exactly "bethTool" (for those who know about Beth Stone's project), but it will provide much of what an HLA user would want from "bethTool".

If you want a tiny idea of what templates will look like in HLA v2.0, take a look at macro definitions in the "Dylan" programming language. HLA templates won't be exactly like Dylan macros, but they will be similar in spirit (though I doubt I'll support the concept of "hygenic" macros).
Cheers,
Randy Hyde
Posted on 2003-12-08 11:00:46 by rhyde
jesus christ are you kidding?? i can't believe my eyes. that would be the biggest help you've ever done to our community. thank you mr. randall hyde.
Posted on 2003-12-08 11:01:24 by evil__donkey

One problem with this kind of feature is that HLA would lose its standardized syntax.

It would'nt be a problem if your coding only for yourself, but if would definitely be a problem if you have to work with other HLA programmers and everybody is used to their own favorite syntax.


Definitely the basic HLA syntax is not going to change dramatically in HLA v2.0. There are going to be some minor changes (that, unfortunately, will break a lot of code), but updating existing software is going to be an easy fix; dramatic changes like flipping the operands just isn't going to happen. Even ignoring technical reasons for keeping ( src, dest ) ordering, the bottom line is that today there are a *lot* of HLA programmers who've gotten used to that syntax and changing that now, even if I wanted to, would only make a few non-HLA users happy (who wouldn't switch to HLA, anyway) and really piss off a lot of existing HLA users.

The good news, however, is that if someone wants to use a different syntax in HLA v2.0, they'll be able to create templates to change the syntax to their heart's content. They may face the ire of other HLA programmers who don't appreciate the non-standard syntax in the source listings produced by such templates, but I'm in the business of providing the tools, not tell people how to use them :-). Such programmers may be treated just like those people who used to use C macros to simulate Pascal statements, e.g.,



#define then
#define repeat do{
#define until(x) }while(!(x))
#define begin {
#define end }
etc.


But if someone really wants to do this, or has a good reason to do it, I don't want to stand in their way.
Cheers,
Randy Hyde
Posted on 2003-12-08 11:06:30 by rhyde

I do use Inno Setup.
Not because it's free, but because it's easy to figure out!
Note: The .iss file for HLA installation is included in the HLA Sources package.

:D Good to hear! Sorry I didn't check it out myself...

:) You're ideas about pre-releases of the source code is IMO a good idea! ;) Keep up the good work!

Best regards,
Tommy
Posted on 2003-12-08 12:09:12 by Tommy