For Linux users, HLA is a strong programming tool that allows them to create powerful programs on a variety of different levels. As HLA becomes more feature-rich, additional applications will be written using HLA under Linux. With HLA and Linux, programmers can develop new and exciting applications anyone can use. Read more.
I’m not sure by what criteria he considers his creation to be assembly language. Looking at the example in the article it looked more like a variant of BASIC meets C/C++. I don’t mean to denigrate his considerable efforts, but it does appear to be a problem looking for a solution.
Im confused. What is HLA supposed to be? What does it have to do with assembly?
I think they are all just macros that are replaced with assembly before compilation. A bit like Microsofts Macro Assembler (MASM) really.
Its used as a learning tool. Input and Output is pretty tough on assembler so the developer created some easy macros so beginners can play with assembly instruction whilst reading and writing the screen easily.
The things we can see on the net! X-D
That’s C with a touch of Python and Pascal. Oh boy….
X-D
What I find very funny is that they haven’t chosen to use a C like syntax for the strings for example.
Frankly what’s so good about (“text” nl) instead of “text
“..
HLA simply allows high level structures in assembly. It is to teach you assembly but slowing going from high level instructures to pure assembly. It allows you to compile programs written in partial assembly, and partial high level syntax. Just read the manual about it.
Do a bit more research before you post. Please.
I’ve looked at HLA before, though I haven’t had the opportunity to create any sample programs with it. It was principally designed as a teaching language for assembly programmers. Therefore it comes with a number of high-range constructs to help programmers get started early out. However if you follow through the HLA course, you learn to work with less high-level constructs and more raw assembly, until at the end you’re using assembly on its own.
It really is a very good way to teach assembly.
With regard to post about the C syntax, take another look. Bar the preprocessor declarations, the syntax is heavily derived from Pascal.
One thing I disagree with is the idea of using it as a general purpose programming language, it wasn’t designed for that, and while I can’t say for sure, I’d imagine programmers would run into awkward obstacles once they moved onto the development of larger, non-trivial applications.
For people looking to use HLA to learn assembly, consider the “Art of Assembly” book: http://webster.cs.ucr.edu/AoA/index.html
Stop b*tching about it. It is what it is, and if you don’t like it, that’s your problem.
Chill out dudes! Check out my assembler: http://betov.free.fr/RosAsm.html
It’s hundred times better!!!
Pardon, but there is only one high-level assembler, and it is called “ANSI C”.
> the syntax is heavily derived from Pascal.
Well being heavily derived from a dead language is not a good idea in my book.
Even universities are ditching Pascal and going to Java for teaching computer science, so students won’t even know Pascal to help them..
But, can you hook it up to the .Net library on Windows?
Probably not.
I used to love assembly, but it’s a bit hard to justify using this for anything other then as a learning tool. Possibly a file copy utility program that runs on a scheduler. For a business programmer it’s hard to find an algorithm that would justify assembler these days.
A game developer might find this interesting.
But, then you’re stuck on just one platform( x86 ) and one OS because the librarys are tied to the os.
HLA is C. Cross-platform, fast. What more can you expect?
Actually Pascal is alive and well in the form of Borland Delphi, which is used to develop a significant number of Windows apps (particularly in the bespoke world). Having used both Delphi and Java in two separate jobs, I can tell you Delphi is the far easier to read, code in, and use. The downside is the small library that comes with it, particularly in comparison with Java, and the smaller community due to it being a commerical product.
The Delphi IDE particularly shines when developing GUI apps. Idea/J is the only Java IDE that’s equivalent. Further, Delphi tends to be a lot more forgiving of programmers bundling stuff into the event loop: multi-threading is still necessary for the big stuff, but more often then not you can get away with it. With regard to the underlying toolkits, Swing is more flexible than Delphi’s VCL and, should you wish to code a GUI by hand, is probably the better choice.
With regard to the choice of syntax, it’s well known in programming circles that Pascal has one of the most readable syntaxes out there, while still being close enough to C for programmers to make the jump. It’s an obvious choice for a teaching language.
Actually, it’s designed to allow users write x86 assembly, which isn’t particularly portable. It may be a high-level assembler, but it’s still assembly you’re writing, and that’s always tied to a particular CPU
from the example you may think that it looks nothing like assembly, simply because the example in the article exclusively uses the high-level libraries.
i have actually written a program recently (designed to interact as a sort of mini-plugin for Opera) in a few hundred lines of HLA, and about 90% of it consisted of more “obviously” assembly instructions such as JMP/MOV/CMP etc. the other 10% called the very handy libraries allowing me to get the commandline parameters without any pain about — i think HLA is an excellent language.
try to understand: there is *nothing* stopping you from writing 100% pure, totally bare-metal assembly within the HLA framework. it’s just that where you want or need, you can also take advantage of some high-level constructs. in my case, commandline parsing. who wants to write that in low-level code for the thousandth time?? you can even sneak in some near regex-like string parsing too.
in short, HLA is a fantastic language. the way it’s designed allows you to start your entire program at a relatively high level and then, as you gradually get more familiar, you can start interleaving it with progressively lower and lower level code. then do what i did, and write the interesting parts in assembly, leaving the drudgery and bits that just simply don’t need it for the excellent library.
I still prefer the good ol nasm and a text-editor.
Some comments and answers to various posts in this thread:
Andy Ross:>>>>>>>>>>
I’m not sure by what criteria he considers his creation to be assembly language. Looking at the example in the article it looked more like a variant of BASIC meets C/C++. I don’t mean to denigrate his considerable efforts, but it does appear to be a problem looking for a solution.
<<<<<<<<<<<<<<<<<&l t;<<
No doubt about it, a high-level assembler like HLA (and there are others, including Microsoft’s MASM) can allow you to write code that doesn’t look anything at all like traditional assembly. This statement is true of *any* assembler that allows one to write decent macros. Paul’s example is extreme insofar as almost all of the code is either standard library calls or macro invocations — you don’t get to see much “real” assembly language in there. However, rest assured that this isn’t the only “programming paradigm” that HLA is capable of. As for what “problem” this product is trying to “solve”, just note that HLA is designed as an educational tool for classroom use, to get students up to speed in assembly language programming as rapidly as possible (e.g., within a 10-week quarter). This is a *difficult* problem when using traditional assemblers.
BTW, if you want to see some additional examples of HLA source files, that better typify what’s possible with HLA, check this out:
http://webster.cs.ucr.edu/AsmTools/HLA/hla_examples/index.html
tbf wrote:>>>>>>>>>>>>>>>> >>>
Pardon, but there is only one high-level assembler, and it is called “ANSI C”.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<<<
There are many “high-level assemblers” available since the 1960s, and none of them are called ANSI-C. A true assembly language (which HLA is) provides direct access to all the CPU’s features, including registers, flags, and machine instructions. ANSI-C provides none of these.
BTW, lest some people belive that HLA is a radical departure from existing assemblers, just note that Microsoft’s MASM and Borland’s TASM are also high-level assemblers, possessing many of the same features as HLA. So those who attempt to claim that HLA is “not assembly language” will have to deal with the fact that their opinions apply directly to two of the most popular assemblers of all time.
Brian Feeney wrote:>>>>>>>>
Bar the preprocessor declarations, the syntax is heavily derived from Pascal.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<
Actually, it would be safer to say “Modula-2” or “Ada”, or simply say “from the Algol-language branch.” In fact, HLA’s syntax for declarations and HLLs was an attempt to select some of the better features from various imperative languages in an attempt to produce source code that is highly readable. Readability was the ultimate goal (which is why HLA favors the Algol branch rather than the C branch). Of course, with all the parentheses in HLA, one could argue that I stole some syntax from LISP, too! 🙂
AtariCheck Wrote:>>>>>>>>>>
But, then you’re stuck on just one platform( x86 ) and one OS because the librarys are tied to the os.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<<
Not true at all. The HLA Standard Library is currently portable between Win32 and Linux. Well-written programs compile and run under either OS with no changes to the source file. For HLA v2.0 (currently under development), plans are to support Win32, Linux, Mac OSX86, BSD, QNX, and Solaris.
Clearly, portability is limited to the x86 platform, but with the recent announcement of Apple’s move to the x86, there really is no need to support other CPUs for personal computer applications.
Interested parties who actually want to *learn* more about HLA might want to check out the following articles:
What is HLA all about?
http://webster.cs.ucr.edu/AsmTools/HLA/HLADoc/HTMLDoc/WhatIsHLA.htm…
Teaching Assembly Language Using HLA
http://webster.cs.ucr.edu/AsmTools/HLA/HLADoc/HTMLDoc/teachingASM.h…
The Art of Assembly Language
http://webster.cs.ucr.edu/AoA/index.html
The main HLA web page
http://webster.cs.ucr.edu/AsmTools/HLA/index.html
Cheers,
Randy Hyde
I thought HLA was called C. I am not joking, isn’t that how people write C compilers?
You insecure java/python/ruby fanboys need to get a grip.
99% of electronic devices have assembled code sitting in a ROM right next to the micro. Civilization would come to a screeching halt if you were to remove assembly from the equation.
In a thousand years, do you think that anybody’s going to care what software was used to track orders at some company? No. They’re going to be ripping EPROMS and flash memory out of everything they can get their hands on in order to find out how the world really worked.
renoX wrote:>>>>>>>>>>>>>
What I find very funny is that they haven’t chosen to use a C like syntax for the strings for example.
Frankly what’s so good about (“text” nl) instead of “textn”..
<<<<<<<<<<<<<<<<<&l t;<<<<<<<
Actually, the syntax for strings *was* mostly taken from C (rather than, say, the Algol-branch of the language tree). You’ll note that HLA strings use quotes while HLA characters use apostrophes (unlike Pascal). You’ll also note that HLA automatically concatenates two juxtaposed string constants appearing in the source file, just as C does.
Now as to why HLA doesn’t support the C escape sequences, well, this isn’t necessary in *assembly language*. You can easily specify the numeric character constants and the assembler will automatically embed those constants directly in the output file. For numeric character constants, I chose to use the Delphi/Turbo Pascal notation, specifically “#” followed by a numeric value. For example, an end of line sequence (under Linux) could be specified by #$a, so you could write something like “Hello World” #$a and HLA would automatically concatenate that character code to the end of the string.
As for the phrase << “Hello World” nl >> just note that there is nothing particularly special about the identifier “nl”. It’s just an identifier declared in the stdio header file. It happens to expand to the sequence <<#$d #$a>> under Windows and <#$a>> under Linux. IOW, it’s a platform-idependent way to specify a newline sequence.
Another place where HLA is different than C with respect to strings is putting a quote within a quoted string. Like Pascal, you double up the quotation marks to get a single quote, e.g.,
“He said “”hello world”” to me”
The *nice* thing about the fact that HLA does *not* use C’s escape character sequence syntax is that it is much easier to create such strings to pass on to other (C) programs and functions that *do* want to see these escape sequences. That is, if you really want to pass the string “hello world
” to some other code, including the backslash and the n (without them being converted to a newline), then HLA’s string syntax is far cleaner.
Ultimately, though, this is just one of those syntactical things that an HLA user is supposed to learn in order to write HLA code. Syntactically, *no* part of HLA exactly matches some part of any other language. That was never the point of HLA. HLA was designed to make it easy for someone who knows an imperative language such as C/C++/C#/Java or Pascal/Delphi/Kylix/Modula-2/Ada to quickly get up to speed in assembly language. The point wasn’t to provide an assembler whose syntax *exactly* matches one of these other HLLs, but to provide statements in the language that have semantics similar to statements in those HLLs. IOW, the goal was to make learning assembly language, after learning an imperative HLL, about as easy as learning a second imperative language. In the classroom setting, it has been quite successfully used for that purpose.
To address the question: <<Frankly what’s so good about (“text” nl) instead of “textn”..>>, I would ask
“What so good about [cout << “text” << endl]?”
Different language, different approach is all.
RenoX also wrote:>>>>>>>>>>>>>
Well being heavily derived from a dead language is not a good idea in my book.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<<<<
As others have pointed out, Pascal is hardly dead. Even if it were, the programming language constructs found in the Algol branch of the programming language tree are generally considered to be superior (in terms of readability) than those on the C side.
>>>>>>>>>
Even universities are ditching Pascal and going to Java for teaching computer science, so students won’t even know Pascal to help them.
<<<<<<<<<
Simply knowing C or Java isn’t going to be sufficient to learn assembly language programming. HLA succeeds as a teaching tool not because of syntactical similarities, but because of *programming paradigm* similarities. A student who has learned how to solve problems using an IF/ELSE or WHILE statement in any of these imperative HLLs will have a pretty good idea how to solve those same types of problems in any other language supporting these statements.
A big problem with (traditional) assembly language is that you don’t have these statements available to you. Instead, you have to learn how to synthesize them using comparisons, conditional jumps, and other techniques. There is a steep learning curve a beginning assembly language student faces when moving from a HLL to assembly. The point of a high-level assembler, such as HLA, is to allow students to employ the HLL programming paradigm early on in their education so that they can begin writing code immediately. If they don’t know how to use compares and branches, but they do know how to use IFs and WHILEs, then provide them with an assembler that lets them use IFs and WHILEs during the first few weeks of their course (while they master other topics).
Of course, no student should complete an assembly language course thinking that IF and WHILE statements are actually assembly language. Certainly, before the course is over, they need to learn about comparisons and conditional branches. But having those HLL-like statements available for use in the early parts of the course saves the students from having to “learn everything all at once” and allows the instructor to spread out the material over the quarter. IOW, a high-level assembler like HLA allows the student to leverage their existing HLL knowledge early in the course so they don’t have to learn everything from scratch before being able to test out ideas in assembly language.
Whether those students know Pascal, C/C++/C#, Java, or any of a couple dozen other imperative programming languages, chances are pretty good they’ll know what to do with an IF or WHILE statement, and after taking a few minutes (or even hours) to learn the HLA syntax for these statements, they’ll be able to use them. OTOH, changing programming paradigms (e.g., to cmp/Jcc) is a *very* time-consuming process.
Cheers,
Randy Hyde
AtariCheck wrote:>>>>>>>>>
But, can you hook it up to the .Net library on Windows?
Probably not.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<
If you can link up any binary executable with .Net library code, then HLA will be no different. If this cannot be done, it would be a failing of .Net, not HLA (or 100s of other languages that emit object files that aren’t MSIL).
AtariCheck also wrote:>>>>>>>>
I used to love assembly, but it’s a bit hard to justify using this for anything other then as a learning tool.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<<<<
HLA has always been promoted as an educational tool. Though several die-hard programmers are writing large applications in assembly (myself included), I certainly don’t expect large numbers of people to write huge apps solely in assembly language (I’ll leave that fantasy to Rene “Betov” Tournois and his “assembly rebirth”).
There is one large application that I’ve justified to write in HLA — HLA v2.0. HLA v1.x (the current version) was written using Flex, Bison, and C (about 120,000-150,000 lines of source code). Using Flex and Bison turned out to be a mistake for many reasons, including (but not limited to): (1) HLA’s grammar is not LALR, so I had to pull some incredible kludges and settle for some obscure defects when using these tools; (2) Flex and Bison are infamous for their inability to handle syntax errors in a nice fashion–not a great thing for a teaching tool; (3) Flex and Bison generate some *huge* tables and the assembler’s executable file is quite large as a result. Also, the parser/scanner tables blow away the cache, producing a slower assembler than necessary. (4) The use of Flex and Bison limits the number of people who can work on the HLA source code (and not in a good way, see below).
Flex, Bison, and C were okay tools for prototyping the language. I always intended to completely rewrite HLA once the prototype was finished (which it basically has been for about a year). When I first started on HLA v2.0 several years ago, I briefly entertained using a different parser generator such as ANTLR. I quickly gave up on this because of a lack of big project experience with ANTLR. I couldn’t guarantee that ANTLR wouldn’t have its own source of problems, just as FLEX and Bison have had.
Because HLA is intended as a teaching tool, a high priority for HLA v2.0 was to improve error reporting and recovery. Ultimately, I chose to use a recurisve-descent predictive parser (with some hacks to handle the non-LL(1) aspects of the HLA grammar) because it’s much easier to provide decent error reporting and recovery with a predictive parser.
At first, I was going to write HLA v2.0 in C. The advantage of doing so what that the code would be portable amongst OSes with little more than a recompile (assuming, of course, the code was carefully written). Ultimately, I chose to write HLA v2.0 in HLA. Why? For the simple reason that I want HLA programmers to be able to work on the HLA source code (and *only* HLA programmers). I seriously doubt that too many people outside of the HLA programming community would be interested in working on the HLA compiler, and everyone in the HLA community *knows* HLA, so using a different language would actually *reduce* the number of people who could work on the compiler (e.g., there are many HLA programmers who don’t know C, so had I chosen C as the HLA implementation language I would have excluded those people).
Some might argue that implementing a large program in assembly language is crazy. People claim that assembly requires 10 times the effort of HLLs. Well, first of all this statement isn’t true, and second of all, HLA contains HLL-like statements so if you’re willing to work in a HLL on HLA source code, then just use the HLL-like control structures found in HLA and you enjoy most of the benefits of those HLLs in assembly. To date, I estimate that HLA v2.0 is about 50% complete (compared to the feature set in HLA v1.x). It is just over 100,000 lines of source code (including about 25,000 lines of machine-generated source code for the scanner). This compares quite favorably to the 120,000-150,000 lines of code in the current VHLL implementation of HLA v1.x. If I had to guess, I’d predict that HLA v2.0 will top out at under 200,000 lines of code. So it won’t be signficantly larger (at least, if you believe those 10x figures people throw around) than the VHLL implementation. The resulting code will be quite a bit smaller (not as many large tables) and will run about two orders of magnitude faster (though this is due more to better algorithm design than the choice of assembly language).
I don’t recommend that most other people should write their large business applications in assembly language, but HLA v2.0 demonstrates that many of the traditional complaints about productivity loss when using assembly language don’t apply to high-level assemblers.
netpython wrote:>>>>>>>>>>>>>>>
I still prefer the good ol nasm and a text-editor.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<<<<<
You’re not alone. NASM is the second most popular assembler on the PC today. The bottom line, though, is that people tend to prefer the first assembler they’ve learned and rarely get excited about switching to a new assembler later. There have only been a few mass defections from one assembler to another and such migrations generally occur for only two reasons:
1. The new assembler has a syntax that is very compatible with the old assembler (e.g., MASM->TASM, NASM->FASM)
2. The programmer switches to a new environment that doesn’t support the old assembler (e.g., Windows/DOS->Linux).
When I released HLA v1.1 to the general public in Sept, 1999, I foolishly assumed that a lot of existing assembly programmers would switch from their existing assemblers to HLA because of HLA’s massive feature set (far more features than MASM and TASM, for example). It only took me a short while to realize how wrong this statement was. Once people have taken the enourmous effort to learn a new assembler, they’re rarely willing to switch to a new one (this is true of programming languages in general, which is why language wars are so common). For that reason, I don’t encourage people who already know an assembler, such as NASM, to switch to HLA. If you already know assembly language, then you’re not the target audience for HLA. I wrote HLA to help students in an assembly course learn assembly language as rapidly as possible. If you know NASM, I’ll assume that you already know assembly language, so you’ve already achieved what I would want to help you achieve.
HLA *is* quite a bit more powerful than the other assemblers out there. I wrote HLA because MASM’s macro facilities didn’t quite cut it for me. Even today, no other assembler comes close to providing the language features you’ll find in HLA (with due respect to Rene “Betov” Tournois’ claim that “It’s [RosAsm] hundred times better”, RosAsm doesn’t even hold a candle to HLA when it comes to assembly language features). However, the bottom line is that assembly language is sooooo marginalized today that the few people who actually do use it generally write short little functions that they call from a HLL. And as such, they never really advance to the level where they use the powerful features of *any* assembler. Lots of HLA users may *use* some advanced macros provided with the HLA Standard Library, but you don’t see too many HLA users writing advanced macros of the level, for example, of the “stdout.put” macro. Even NASM or FASM users rarely write sophisticated macros that tax the abilities of their assemblers, so it’s hard to imagine a typical NASM user wanting to switch to HLA because HLA offers more “power”.
Cheers,
Randy Hyde
Anonymous wrote:>>>>>>>>
I thought HLA was called C. I am not joking, isn’t that how people write C compilers?
<<<<<<<<<<<<<<<<<&l t;<<<<<<
Early on, C garnered a reputation as a “lower-level” language because it offered bit-manipulation operations that were absent from most other popular HLLs at the time. At the time C was created, “bit twiddling” was pretty much the domain of assembly language, so when C introduced these facilities (and a few other facilities that mapped directly to PDP-11 machine instructions, such as the “++” and “–” operators), people began claiming that C was a low-level language.
Of course, it didn’t help things that the C language itself contained no built-in I/O (common in most other languages) and relied totally on library routines for this facility (just like assembly languages did).
Time passed, and languages became ever more higher level (think Java, Python, Ruby, etc.) and from the perspective of these programmers, C become the new “low-level language”.
But C is *not* an assembly language, but definition. C is architecture-independent (well, within reasonable bounds) and you do *not* have access to low-level machine facilities in the C language. If C were truly an assembly language, for example, why would the need exist for “in-line assembly” sequences?
As for how people write C compilers, I have no idea what you mean by the question “isn’t that how people write C compilers?” One might argue that a few (non-standard) C compilers for embedded processors are written to replace assembly language, but ANSI-C is not an assembly replacement. You don’t get access to the underlying machine, which is what assembly language is all about.
Cheers,
Randy Hyde
Is it any good for writing shellcode?
Anonymous wrote:>>>>>>>>>>>>>>>
Is it any good for writing shellcode?
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<<<<<
Well, one gentlemen is using HLA code to write CGI scripts to maintain a web site.
HLA’s Standard Library includes an extensive collection of string and pattern matching functions (similar to what you’d find in Icon or SNOBOL4), so doing stuff you’d use PERL for is not out of the question (though do keep in mind that we *are* talking about assembly language here, even if there are all these nice macros that give it a VHLL-like flavor).
Of course, you can read the stdin, write to the stdout, and execute shell commands from an HLA program, so depending on exactly what you mean by “shellcode” the answer is probably “yes”. Exactly how much less convenient this would me (than using some other scripting language) is certainly open to debate. But the fact that *someone* out there is using HLA to run his web server should tell you something about the convenience and capabilities of HLA (or, perhaps, the diposition of that that programmer 🙂 ).
Cheers,
Randy Hyde
Not all institutions are moving away from Pascal towards Java as a teaching language. Some, that care about teaching computer science rather than how to use language L, choose languages appropriate for teaching. It is almost always better to use a language that isn’t really popular for this purpose.
This is one of the reasons why the University of Glasgow Computing Science department choice Ada back in 1994 as the replacement for Pascal and still uses it today. There were other reasons: language features, availability of compilers for various platforms (gnat helped a lot here!). The same department also uses Haskell, C and Java in teaching but level 1 courses are Ada.
> Now as to why HLA doesn’t support the C escape sequences,
> well, this isn’t necessary in *assembly language*.
Well it isn’t *necessary* in C too: with the preprocessor and string concatenation, you can write:
#define nl “13”
printf(“toto” nl);
instead of “toto
“, but apparently K&R thought that the escape sequence was a good idea, and I agree with them: relying on string concatenation to build basic strings isn’t “nice”.
I’m not sure I understand your justification to use a different escape character, if you send a string ‘toto
‘ to a C program, it will see ‘t’,’o’,’t’,’o’,<the ASCII value of
‘>,0 and it will work!
No need to have ‘t’,’o’,’t’,’o’,”,’n’,0 passed to the C program!
And about:
> what so good about [cout << “text” << endl]?
I would say: nothing! As shown by the fact that no language after C++ have reused this poor syntax, prooving that this was really not a good idea.
Anyway, you can defend your syntax choice anyway you want, it still remains that quite a few people here found it not very pretty.
Maybe we’re too tainted by C, but as the C/Java/C++ number of users is much, much more bigger than the Pascal/Ada’s, I have some doubt about HLA success..
Although I must admit my short attentionspan meant I never made it through the introduction of AoA 😉
And about:
> what so good about [cout << “text” << endl]?
I would say: nothing! As shown by the fact that no language after C++ have reused this poor syntax, prooving that this was really not a good idea.
The reason that neither of you found anything good in this is because you did not understood the point here is operator overloading. In certain circumstances, “endl” might not be ”
“, but in C++ iostream, you retained the symbolic logic and portability.
You can also overload “<<” with output for a matrix, which you can never handle by pure string concatenation.
The *nice* thing about the fact that HLA does *not* use C’s escape character sequence syntax is that it is much easier to create such strings to pass on to other (C) programs and functions that *do* want to see these escape sequences.
I think arguing this is “nice” is quite far fetched.
That is, if you really want to pass the string “hello worldn” to some other code, including the backslash and the n (without them being converted to a newline), then HLA’s string syntax is far cleaner.
Can you also give a compelling reason why most people and in most cases want to do stuff like this? Unless in situations like writing a C parser, there is actually no good reason for this, especially in mixed programming environment. The escape sequences in C are immediately translated by the compiler into their ASCII representation (and not by run time hooks in the I/O library), and you must have users with C-escape interpreting eyes if you see a point to pass strings with literal C escapes to e.g. printf.
I have the feeling that you are simply trying to defend some not really helpful ideosyncracies.
>>>> ylai replied to:
The *nice* thing about the fact that HLA does *not* use C’s escape character sequence syntax is that it is much easier to create such strings to pass on to other (C) programs and functions that *do* want to see these escape sequences.
——
I think arguing this is “nice” is quite far fetched.
<<<<<<<<<<
Having used this facility to write C code from program’s I’ve written, I would hardly call it “far fetched”.
he also wrote:>>>>>>>>>>>>
Can you also give a compelling reason why most people and in most cases want to do stuff like this?
<<<<<<<<<<
In most case, of course not. People typically don’t write code that generates C code in most cases.
Then again, what’s the big deal with support Pascal-like string rather than C-style strings? If I’d supported C-style strings, then the people on the *other* side of the fence would complain. Keep in mind, HLA is *not* C. It’s its own language and there never was an intent to duplicate C. Indeed, of all the languages out there *too* duplicate, C comes in pretty low on the list because of its well-known readability problems. As someone else has pointed out, the main contribution C made to HLA was in the design of some of the compile-time language (preprocessor in C) facilities. C’s preprocessor did those fairly nicely compared to other languages. Borrowing quotes and apostrophes from C was another good thing. But C’s escape sequences are *not* particularly readable or an amazing good thing to have in a language, hence, they were not adopted.
continuing:>>>>>>>>>>>>
Unless in situations like writing a C parser, there is actually no good reason for this, especially in mixed programming environment.
<<<<<<<<<<<<<<<<<&l t;<<<<<
And the good reason for supporting C escape sequences in a non-C language is?
and more:>>>>>>>>>>>>>
The escape sequences in C are immediately translated by the compiler into their ASCII representation (and not by run time hooks in the I/O library), and you must have users with C-escape interpreting eyes if you see a point to pass strings with literal C escapes to e.g. printf.
<<<<<<<<<<<<<<<<<
I’m not sure I see the point you’re trying to make. Obviously, you seem to believe that C’s way of doing character strings is the only way to accomplish the task. Great. Feel free to do it that way when you create your own language. I happen to disagree and chose to do it a different way in the language I implemented. Thus far, you’re the *only* person I’ve ever heard complain about this. That doesn’t put it very high on my list of priorities to change in the language.
Cheers,
Randy Hyde
Anonymous wrote:>>>>>>>>>>>
Thanks for the toy language. Real developers will stick to something productive like masm, instead of a pathetic sales pitch for your lego masterpiece.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<
Are you refering to HLA here?
From http://webster.cs.ucr.edu/AsmTools/HLA/HLADoc/HTMLDoc/WhatIsHLA.htm…
Design Goals and Decisions
HLA was originally conceived as a tool to teach assembly language programming. In early 1996 I decided to do a Windows version of my electronic text “the Art of Assembly Language Programming” (AoA). After an attempt to develop a new version of the “UCR Standard Library for 80×86 Programmers” (a mainstay of AoA), I came to the conclusion that MASM just wasn’t powerful enough to make learning assembly language really easy. I decided to develop an assembler with sufficient power, providing the tools for a good standard library as well as satisify some other requirements. The High Level Assembler was the result of this.
HLA’s high-level control structures were based on the same concepts found in MASM (which also supports IFs, WHILEs, HLL-like procedure calls, and the like). Like MASM, HLA fully supports complex data structures like records and unions (and goes one better and support object-oriented programming with classes). Fundamentally, the big difference between HLA and MASM is the “compile-time language” (known in other assemblers as the “macro language” or “preprocessor”). As I pointed out in the paper “What is HLA?”, what I needed was an assembly language that was quite a bit *more* powerful than MASM to do the job I needed done for my classes. Unless HLA was going to offer a substantial gain over MASM, there would have been no need to write it, as I’d been using MASM in my courses for about six years at that point (using the 16-bit edition of AoA).
No doubt, MASM users will continue sticking to MASM, just as NASM users will continue sticking to NASM and FASM users will stick to FASM, etc. Usually, this has nothing to do with the “power” of the assembler, but the fact that people are unwilling to learn the syntax of a new language when they’re reasonably happy with the one they already know. And, in my experience, *few* assembly language programmers exploit the macro processing facilities to the same level I did when I first decided to write HLA, so they don’t have the motivation to go and learn a more powerful assembler.
OTOH, HLA has proven extremely successful at teaching new assembly programmers how to code in assembly language. As they aren’t carrying around the baggage of already knowing an assembly language syntax, and they’re most interested in learning assembly as efficiently as possible, HLA works out real well for them.
As for MASM, it does have one serious drawback — it’s really only a Win32 product (yeah, I realize it’s also DOS and OS/2, but get real about those OSes). If someone decides to move on to Linux (or some other OS), they have to kiss MASM goodbye. You’ll note that the original article was published in Linux World. Guess what? No matter how much that “real developer” you’re talking about would like to do it, they won’t be able to use MASM to develop Linux code.
Cheers,
Randy Hyde
I’m not sure I see the point you’re trying to make.
Sorry, but then you clearly did not understood my point.
Obviously, you seem to believe that C’s way of doing character strings is the only way to accomplish the task.
Sorry, this is just a product of your own imagination. Otherwise feel free to literally quote where I suggested this! Maybe you should try to better understand my few paragraphs.
Now since you fail to comprehend the point: It is not about the only way to do certain things. Just bringing the ability to intermix with C is not a good or compelling reason to explicitly avoid the C notation.[/i]
But again, you clearly fail to comprehend this as my only complaint, to bring C as reason not to support C escapes. As you wrote yourself:
Then again, what’s the big deal with support Pascal-like string rather than C-style strings? If I’d supported C-style strings, then the people on the *other* side of the fence would complain.
Well, this does not sound as a reason why explicitly to avoid C escapes. Or in other word, it is just an arbitrary choice. And then you go on with the readability issue:
C comes in pretty low on the list because of its well-known readability problems. […] But C’s escape sequences are *not* particularly readable […]
Readability issue is a subjective matter (or better: matter of taste and possibly prior training of the person sitting in front of the computer). Please, again, do not intermix it with C escapes as being technically a bad idea.
And the good reason for supporting C escape sequences in a non-C language is?
I think you forgot what I have wrote at this point. It certainly has advantages for people programming intermixed C with another language. But again, you resort here to the “inverse problem”, and avoids the issue that it is simlply not a technical reason not to use the C escape sequence.
I’ve used HLA and I generally liked it, the syntax relied a bit too much on parentesis for my liking. the standard library on the other hand was superb, Hla is definately no more a toy assembler than Masm. that said, I rarely touch assembly these days, and judging by the two win x86 assembly boards I sometimes check in on, it seems much less active nowadays. here’s hoping it will pick up again.
How does it deal with side effects of library function calls and higher-level control constructs, e.g. modified registers and flags? Don’t they confuse students?
Oh c’mon, it’s rather widely known that C doesn’t score high on the ‘easy-to-read’ rankings.
(for that matter I prefer J even, nice and terse, and consistent operator precedence)
Oh c’mon, it’s rather widely known that C doesn’t score high on the ‘easy-to-read’ rankings.
That depends heavily on factors like (I mentioned) training, personal “reading taste”, and ultimatively the program itself. Perfectly indented FORTRAN77 with tons of goto is not going to score higher on your “easy-to-read” raking, even being less “symbol-loaded” than C. And on the other hand, 2/3 level loops is also not making an equivalent Pascal code more readable than Fortran 95 with direct array assignments.
There is simply no language XY => unreadable logic. Also arguing that assembly, even HLA is easier to read comes very close to a joke.
But all this is simply irrelevant for the discussion. There is plainly no technical reason to avoid C escapes, and attempting to say that this is needed for string passing is plainly not true. Niche such as C parser is certainly not the typical application for HLA.
Have a look at the german documentation:
http://www.menuetos.org/appl/sp.pdf
and the in english written side at
http://web.archive.org/web/20030413081814/www.goosee.com/menuetos/
http://web.archive.org/web/20040219044801/www.goosee.com/menuetos/
Sphinx C– is a C language compined with ASM. Or mostly ASM with C like macros or what ever it is.
not quite sure why you’re so hung up on C escape sequences… i also don’t see you actually give a technical reason you think they should be preferred – which isn’t terribly surprising, as there isn’t one. it’s just style. if you can offer a technical reason c-style escape sequences are better i’d be rather intrigued.
Nimble asked:>>>>>>>>>>>
How does it deal with side effects of library function calls and higher-level control constructs, e.g. modified registers and flags? Don’t they confuse students?
<<<<<<<<<<<<<<<<<&l t;<<<<<<
Let’s separate the discussion of library function calls and HLL-like control constructs, as the answers are completely different.
For control structures, HLA adopts a very simple policy, with few exceptions (noted below), HLA does not modify any general-purpose registers. Changing register values behind one’s back would be confusing for experienced assembly programmers just as it would for beginners. That’s pretty much a no-no.
To achieve this, HLA *does* place some restrictions on the type of boolean expressions one can have in a control structure like IF or WHILE. In particular, when you have an statement like:
if( eax = ebx ) then … endif;
the components of the expression must contain items that are compatible as operands to the x86 CMP instruction. That is, “xxx = yyy” requires that CMP( xxx, yyy); must be a legal x86 instruction. This means, of course, that you cannot compare the values of two memory locations (and a few other, minor, restrictions), but the end result is that you don’t wind up modifying any general purpose registers. Of course, the *flags* do get tweaked, but this is an expected by-product of a comparison operation.
Yes, beginners have to learn what’s allowed and what’s not allowed in boolean expressions in a control structure. But this is a *GOOD THING*. Because they need to learn these same restrictions as they apply to most native x86 instructions like CMP, ADD, AND, OR, and so on. Later, when they progress beyond using HLL-like control structures, they will be used to the fact that you can’t do memory to memory operations (and when they learn about the actual machine instructions, they will learn *why* those restrictions exist).
As for standard library calls, most HLA Standard Library routines preserve all registers unless they actually return some value in a register.
A beginner *can* get into some problems if they’re not paying attention. Consider the following HLA statement:
if( str.eq( string1, string2 ) ) then
.
.
.
endif;
str.eq is an HLA standard library routine that compares the two strings you pass it as parameters and returns true or false in the EAX register, depending on the outcome of the comparison (equal or not equal). In the IF statement, HLA substitutes “EAX” for the str.eq procedure call (an activity in HLA known as “instruction composition”). It *is* easy to forget that str.eq returns a value in EAX and, therefore, wipes out the EAX register. This fact is not immediately obvious to someone quickly reading this code. However, the return values (and side effects) of the HLA Standard Library routines *are* documented, so you cannot blame this issue on HLA or the standard library. The same problem would exist if the user wrote their own procedure and used it in this manner.
One of the two places where HLA will change a register (actually two) behind your back is in a call to an object’s method. Whenever you invoke an object’s method, HLA loads ESI with the address of the object and EDI with the address of the object’s virtual method table. Again, this behavior is documented in the HLA documentation, so it shouldn’t come as a suprise to anyone using objects in HLA (and, to address the “beginners” portion of your comment, most beginners aren’t doing object-oriented programming in assembly language anyway, so this issue generally doesn’t apply to beginners).
The other place where HLA will change a register behind your back (at least, by default) is in the code that HLA automatically generates for entry into and exit from a procedure. HLA, by default (you can turn this off easy enough), will emit the code to push EBP and set up the activation record for the procedure. Likewise, HLA emits code to clean up the stack upon exiting the procedure. Beyond being a major convenience (because HLA pretty much emits the same code an advanced programmer would use with most procedures), this also allows beginning programmers to write simple procedures and access things like parameters and local (automatic) variables without having to know about activation records and constructing stack frames. Obviously, those students need to learn this information before completing their assembly education, but by having HLA emit this code automatically, this advanced information can put put off a couple of weeks in the course. The end result is that HLA *does* emit code that modifies the EBP register upon entry/exit in a procecure, but the modifications are pretty much what one would expect anyway.
AFAIR, these are the only two areas where HLA will emit code that modifies the registers behind the programmer’s back. The only other place where it would be *nice* to modify a register in the HLA language is when pushing an address for a pass-by-reference variable. To push an address, HLA *must* use a general-purpose 32-bit register (HLA actually uses EAX). However, HLA goes to great lengths to preserve EAX in this case, unless you explicitly tell HLA that it’s okay to use some 32-bit register without preserving it.
Cheers,
Randy Hyde
ylai wrote:>>>>>>>>
I think you forgot what I have wrote at this point. It certainly has advantages for people programming intermixed C with another language. But again, you resort here to the “inverse problem”, and avoids the issue that it is simlply not a technical reason not to use the C escape sequence.
<<<<<<<<<<<<<
Let’s just leave it at this: HLA is *not* C. As pointed out already, most of the HLL-like syntax were derived from the Algol branch of the language tree rather than the C branch. C’s use of apostrophes and quotes to differentiate strings and characters is a *good* thing, IMO, but C’s escape sequences are not (again, IMO). Therefore, while I chose to adopt the C scheme of quotes and apostrophes, I chose to adopt the Pascal/Modula-2/Ada/etc. approach to embedding quotes within strings and the traditional *assembly language* way of embedded non-graphic symbols in HLA strings.
There are many things in HLA that aren’t particularly convenient for C programmers. If they don’t like it and they don’t want to use HLA because it doesn’t support C escape sequences in character strings, they can always use Gas, which does.
In general, C is not a good syntax to base a language upon if you’re interested in producing a language that makes it easy to write readable code. Given that assembly language has a lot working against it in the readability department anyway, it’s better *not* to adopt syntax from some language if there is a better syntax available.
Now we can argue all day long about whether C escape sequences are more readable than the approach HLA takes. However, having taught Assembly, Pascal, C, C++, and Ada at the university level for over ten years, I’ve got a pretty good feeling about what students find readable, and let me tell you that the average student finds C escape sequences confusing. Just my observation; but sufficient to convince me *not* to use that scheme in HLA.
Cheers,
Randy Hyde
Ylai responded to:>>>>>>>>.
Oh c’mon, it’s rather widely known that C doesn’t score high on the ‘easy-to-read’ rankings.
…with…
That depends heavily on factors like (I mentioned) training, personal “reading taste”, and ultimatively the program itself.
<<<<<<<<<<<<<<<<<
Obviously, anyone can train themselves to believe that some piece of code is “very readable.” However, the readability metric is not based on what one person thinks, but what the programming community at large thinks of the code. The fields of software engineering, psychology, and graphic arts have made considerable contributions to answer the question “what is readable code?” And that research has made a *huge* point of eliminating “personal reading taste” from the equation. Anything built on “personal reading taste” is going to be subjective, at best. The phrase “readable code” generally implies that *most* people can read and comprehend the code, not just those who share the same “personal reading taste” as the original author.
ylai also wrote:>>>>>>>>>>>>>>>> >>>>>
Perfectly indented FORTRAN77 with tons of goto is not going to score higher on your “easy-to-read” raking, even being less “symbol-loaded” than C.
<<<<<<<<<<<<<<<<<
Yes, it is a well-known fact that you can write unreadable code in *any* language. That’s not the issue. The question is “how easy does a language make it to write readable code?” For example, FORTRAN IV *forces* you to use those same goto statements; you have no choice. FORTRAN77, OTOH, provides (good) structured control statements, making structured programming possible. This makes it *far* easier to write readable code in F77 than in FIV.
Ylai continues:>>>>>>>>>>>>
And on the other hand, 2/3 level loops is also not making an equivalent Pascal code more readable than Fortran 95 with direct array assignments.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<
Yes, language facilities make it easier to specify abstract operations in a more readable form. This is one of the failings of C (and assembly language, to be fair): there are so few very high-level abstractions available. This is why C (and assembly language) programs are often considered to be less readable than programs in high-level languages.
ylai continues:>>>>>>>>>>>>>>
There is simply no language XY => unreadable logic.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<<<
No, but there are many languages {a,b,c,…} that have features that make it easier to write readable programs than the languages in a second set {x, y, z, …}.
For example, Pascal might be in the first set, and C might be in the second set for many problem domains. Functional languages might be in the first set and imperative languages in the second set for other problem domains.
For generic programming problems in imperative programming languages, most people feel that C is in the second set.
ylai continues:>>>>>>>>>>>>
Also arguing that assembly, even HLA is easier to read comes very close to a joke.
<<<<<<<<<<<<<<<<<&l t;
Your statement is incomplete. “easier to read” than what? There is no question that assembly language (even HLA) tends to fall into the second set of languages I was describing above. And *traditional* assembly languages are among the *worst* when it comes to helping you write readable code. One important design goal of HLA was to make it possible to write more readable assembly language programs. To achieve this goal, HLA adopted certain syntactical elements from various HLLs that have well-known, and good, impact on the readability of code. Does this mean that HLA is going to be easier to read than C? Of course not. What it does mean is that it’s going to be a lot easier to write easier to read HLA source code than it will be to write easier to read MASM (or fill in your favorite traditional assembler here) source code.
To achieve this goal, HLA approriated some of the *better* syntactical elements from various HLLs and avoided those items that had superior alternatives. For example, HLA uses statements like IF..ENDIF rather than the Pascal IF <stmt> or C’s if <stmt> because these blocked statements are generally easier to read than the “statement plus compound statement” that Pascal and C use. Likewise, I chose a variation of C’s syntax for conditional compilation directives because C’s syntax is generally better than the alternatives I’ve seen. As for strings and escape sequences, better solutions exist out there than the C-style character escape sequences, so I chose a different path than C.
ylai continues:>>>>>>>>>>>
But all this is simply irrelevant for the discussion. There is plainly no technical reason to avoid C escapes,
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<
I suppose this would be true if you don’t consider readability a technical reason. Then again, what’s the technical reason for *using* C escape sequences?
Cheers,
Randy Hyde
C escape sequences are ugly, jumbled in like that with everything else. I’m GLAD he chose not to use them, and it’s not like they WON’T be translated to whatever they need to be translated to when the asm is parsed and linked (remember, we don’t “compile” assembler). Technical reasons aside, giving novice student programmers clear, readable code is MUCH more compelling than any interoperability.
C++ reuses the bitshift “<<” and “>>” operators because, conceptually, they seemed the best way to express the idea of shifting ANY data into a stream or from a stream to a variable. So, when you overload them for your custom made unions, structs, objects or whatevers, you preserve the symbolic pattern of “into” and “out of”. Others would have chosen differently, that’s fair.
–JM
not quite sure why you’re so hung up on C escape sequences.
It is simply because I do not get the logic why easier interfacing with C is supposed the reason to not do strings in C syntax.
.. i also don’t see you actually give a technical reason you think they should be preferred
If you do not stop at my first sentence, you should noticed that I made it very clear: There are obviously none. It is simply a matter of choice and not for some objective/technical reason, as it was stated.
I’m a little confused as to what the most recent documentation is for AoA? Is it the printed book or the online version? And do you have plans for updating the online version? or are you just going to wait till HLA 2.0 to update everything?
It seems to me that assembly is currently used primarily by compiler writers or those who need specialized/optimized functions in another HLL. I’m interested in using assembly in conjunction with C++ mostly to impress my teachers but to also optimize certain algorithms that I’ll be required to write such as sorting, compression, and encryption.
I’ve read many posts to the GCC mailing list concerning the appropriate use of assembly in modern programming. From those posts, they raise an interesting point as to how (specifically) a C or C++ compiler treats inlining asm. They argue that the compiler should have precendence as to how to handle code generation thus overriding (in the majority of intances) the hand-coded asm blocks. Is the only option to compile the C++ code to an intermediate asm file and manipulate that file directly?