Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Programming Software IT Technology

High Level Assembly 53

dunric writes "Randall Hyde has developed a programming language called High Level Assembly (HLA). It is a great way for new programmers to develop applications for both Windows and Linux. It works with a variety of assemblers, including Gas, Fasm, Masm and others. The website for Randy's HLA is located at: http://webster.cs.ucr.edu/"
This discussion has been archived. No new comments can be posted.

High Level Assembly

Comments Filter:
  • by MrIrwin ( 761231 ) on Monday May 31, 2004 @08:01AM (#9295445) Journal
    ....Sun students get to perfect thier cross platform techniques by programming the JVM natively.

    BTW, PLC's are commonly programmed in "assembler", but the industrial automation worlds idea of Assembler is remarkebly similar to this HLA.

  • by Anonymous Coward on Monday May 31, 2004 @12:08PM (#9296744)
    Exactly like SAL (Simple Assembly Language). MIPS/Spim is a processor/assembly language (MIPS) and an assembler and emulator (Spim). Spim is a great tool in itself. SAL was added onto Spim as a teaching tool.

    We (Goodman [wisc.edu], et al) designed SAL back in 1990 when the CS354 Computer Organization and Programming was moved from VAX. I was a TA at the time and added the SAL code onto Spim.

  • Re:FAQ (Score:3, Interesting)

    by aminorex ( 141494 ) on Monday May 31, 2004 @12:16PM (#9296785) Homepage Journal
    For some of us, the ability to use assembly-language
    to optimize critical sections on sensitive platforms
    or to access memory-mapped hardware registers
    is the sine qua non for the very option of
    writing portable code. Absent this ability, we'd
    have to write entire systems in low-level asm.
  • That's the question nobody can answer. I have quite alot of experience with the author, Randall Hyde, and can tell you in no uncertain terms he beyond a brilliant programmer. He also suffers from some kind of pathology such as megalomania or manic depressive disorder.

    Nobody can answer the question -- why do you need a language that has none of the advantadges of assembley, AND none of the advantadges of a higher level language?

  • by waterbear ( 190559 ) on Monday May 31, 2004 @02:27PM (#9297465)
    HLA looks like a complex programming environment.

    Assuming a common role of assembler, to fine-tune a critical smallish bit of code, I can see the convenience of having a higher level than normal of language constructs. It can make the flow of logic more transparent, (e.g. nestable conditional blocks, loops with readable criteria, repeat-until, do-while, switch/case structure, etc).

    On the other hand, providing this kind of pseudo-high level language structure in assembler programs has been around a long time, and can be done more simply. I still have an assembler macro library around that in its original version (circulated on 80s bbs networks) did this for at least some early versions of MASM and TASM.

    (Most of the identifiers would probably have to be changed for compatibility with newer assemblers because it used non-standard initial characters to enable constructs looking a bit like (ignore the 1--- 's, they just adjust formatting in the Slashdot editor)

    1---- .if (test)

    1---- .orif (another test)

    1------ (whatever code)

    1---- .else

    1-------- .while (yet another test)

    1----------- (whatever other code)

    1-------- .endwhile

    1---- .endif

    and suchlike constructs).

    As I first read it, it was a macro library carrying a by-line from 'Jim Holtman, 1982'. It was not very big, the whole thing (even after some more macros for other logic-extensions were added)came to an include-file size of no more than about 10 kb.

    Maybe it's not clear why anything bigger would be needed.

    -wb-
  • by schwaang ( 667808 ) on Monday May 31, 2004 @03:24PM (#9297760)
    In my day, we learned MIC-1 and MAC-1 from Tanenbaum's book "Structured Computer Organization", and we liked it.

    Google tells me the kids use java to simulate [highpoint.edu] it now.

  • Re:wow, displays (Score:2, Interesting)

    by Anonymous Coward on Monday May 31, 2004 @05:51PM (#9298740)
    It's been about 10 years since I've written a compiler, but displays are an optimization for statically scoped languages that allow nested procedures. Examples of static scoping with nested procedures are Pascal and Java. Your call stack may be 100 levels deep, but a procedure nested 3 deep only ever needs to look at 3 of those entries to resolve variables. A display lets you access those variables without walking the entire call stack. You can't just statically analyze your way around that problem. If you've been looking at C compilers then it's a different story since they don't allow nesting.
  • by Anonymous Coward on Monday May 31, 2004 @09:19PM (#9300024)
    I used to program a computer which only had BASIC (a Sinclair ZX-81 like).

    After some time, I decided hex codes sucked big time. So I decided to code an assembler in BASIC.

    Also, I always found assembly syntax awkward... so instead of:

    LD HL, DE

    I would write:

    HL := DE

    Pascal-like, but no semicolon at the end. Memory references were like:

    A := MEM[HL] .... equivalent to LD A,(HL)

    JMPs were written as GOTO, while conditional branches were written as:

    IF A <> 0 THEN GOTO LABEL, meaning JNZ LABEL.

    EQUs were CONSTS, DWs were INTEGERS, DBs were CHAR (or BYTE, more probably).

    I had a lot of fun.

    The first thing I wrote was the assembler itself, just changing the BASIC commands to my above described lingo.

    It took the BASIC program one entire hour to "assemble" it. Later, I used the same code thru the newly generated assembler. It was assembled in nearly 60 seconds.

    At first, I thought it had failed... :-)

    Those were the good times...
  • by gfody ( 514448 ) on Tuesday June 01, 2004 @06:05PM (#9309162)
    optimizing a section of code in asm is about what 99% of asm programmers do these days. code that requires such optimizations will always be around. typically any place you have an "inner loop" that could be nested within several outer loops that actually gets executed millions or billions of times.. that's when even a single redundant instruction or calculation that takes a few clock cycles can cost you seconds minutes or hours in the final execution time.

    dsp and rendering are two areas I have experience optimizing inner loops for. sometimes you can split up the work at a higher level to run on seperate machines. sometimes you can't. it's _never_ a case of you could always split it up, and it would be easier than optimizing the inner loop in asm. most of the time figuring out how to split up a task to be executed on seperate machines is much more involved than optimizing redundant instructions out've an inner loop.

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Working...