richard hunt

I hope I have not posted this to the wrong ng. I think this is the right
one though. Apologies otherwise.

I have just started trying to learn x86 assembly by following "The Art
of Assembly" in linux using hla. However, I have struck trouble in
Volume 3 in the first chapter. When I try to run example programs that
use the `bound' or `into' instructions then the program pauses for a
second (there is not an increase on cpu load) and then segfaults. This
is using the example programs for Art of Assembly, so I assume this is a
bug

However, I could just be doing something stupid. Any ideas? I have sent
a `bug report' to Randall Hyde, but have not yet received a reply, so I
thought I would write here for advice.

On another note, is `The Art of Assembly' the best free introductory
book about x86 assembly? I like it, because of all the details it goes
into about what is going on in the hardware. In this way it is similar
to the only other assembly book I have read (`Advanced Assembly
Programming for the BBC Micro', which was really an introductory book as
far as I could tell. BTW this was only 4 or 5 years ago, I decided it
would probably be easier to learn 8bit assembly than doing on my pc.
It's funny how many of the concerns involved in 6502 assembly are pretty
much nonexistent in 32bit x86, eg. how to divide, or how to cope with
16bit numbers.)

Sorry about that tangent... Anyway, any advice would be appreciated.
Here is the output when I run `hla -v bd.hla':

----
HLA (High Level Assembler)
Released to the public domain by Randall Hyde.
Version Version 1.52 build 8171 (prototype)
ELF output
Using GAS assembler
GAS output

Files:
1: bd.hla

Compiling 'bd.hla' to 'bd.asm'
using command line [hlaparse -v -sg "bd.hla"]
HLA (High Level Assembler) Parser
Released to the public domain by Randall Hyde.
Version Version 1.52 build 8171 (prototype)
File: bd.hla
Output Path: ""

Compiling "bd.hla" to "bd.asm"
Compilation complete, 17348 lines, 0.146 seconds, 118822 lines/second

Assembling "bd.asm" to "bd.o" via [as -o bd.o "bd.asm"]
Linking via [ld -o "bd" "bd.o" "/usr/hla/hlalib/hlalib.a"]
----

as -v: GNU assembler version 2.12.90.0.1 (i386-linux) using BFD version
2.12.90.0.1 20020307 Debian/GNU Linux

gcc -v: Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)

I am running Debian v3.0r0 on an AMD K6/2 400, and also on an AMD Athlon
1GHz, both with the same problem.

When I use the same version of hla with masm32 I do not have this
problem, but I do not normally use windows, so I want to learn assembly
in my native environment.

Thanks,
--
Richard Hunt

We apologize for any abuse of semicolons in this posting. Any misuse is
unintentional, and not intended to offend.

charles a. crayne

On Sat, 02 Aug 2003 23:22:15 GMT
Richard Hunt


:When I try to run example programs that
:use the `bound' or `into' instructions then the program pauses for a
:second (there is not an increase on cpu load) and then segfaults. This
:is using the example programs for Art of Assembly, so I assume this is a
:bug

What Randall is trying to do is to let students use interrupt handling routines
without having to explain how they work, which makes it almost impossible for a
student to debug. I suggest that you skip over this particular example and
continue with the course.

-- Chuck

randall hyde

Not at all. There are not interrupt handling routines involved here.
The operating system raises an exception, the HLA program uses
the try..endtry block to capture the exception. Not any different than,
say, Delphi or C++'s exception handling routines (e.g., you don't need to
know anything about "interrupt handlers" to use exception handling in
those languages).
cheers,
Randy Hyde

randall hyde

First, try upgrading to HLA v1.54.
There were several code generation problems with Gas
that were introduced since v1.43 that were fixed in the
v1.54 release.

Then, if you'd tell me exactly which program you're having
problems with, I'd be happy to boot up Linux and take a look
at it.

Cheers,
Randy Hyde

richard hunt

Sorry, I'm just learning this newsreader (slrn). First time I've used
usenet since about 96/97. Emailed instead of posted by mistake

I'm afraid that the v1.52 prototype is the version I get when I install
1_54hla.tar.gz. You say that problems were introduced since v1.43. I
checked, and believe it or not the last version I tried was v1.43, and
it had exactly the same problem. I didn't try 1.43 in windows though.

There is no fatal error assembling the code, and the program runs. The
problem happens when I type in a number below 0 or above 10, which
activates ex.BoundInstr. Then there is a short pause (<1sec) and the
program (./bd) segfaults. I have checked, and I have the same problem
with the following /into/ example program.

Since I found this problem I have installed hla/masm32 in windows, and I
do not have this problem. I am happy to continue using the windows
version for the moment, but I thought I should report the problem. Could
it be something particular with my installation? I installed as per the
instructions in the newest version of aoa. Thanks.

--
Richard Hunt

We apologize for any abuse of semicolons in this posting. Any misuse is
unintentional, and not intended to offend.

charles a. crayne

On Fri, 08 Aug 2003 04:40:14 GMT


:The operating system raises an exception, the HLA program uses
:the try..endtry block to capture the exception. Not any different than,
:say, Delphi or C++'s exception handling routines (e.g., you don't need to
:know anything about "interrupt handlers" to use exception handling in
:those languages).

I wasn't trying to disparage the technique, but rather merely to point out that
when it don't work, as is the case in Richard Hunt's environment, students have
no real chance of debugging them.

Out of curiosity, I installed HLA on my Redhat 8 system, but I haven't been able
to get even has far as Richard. Here is what I get trying to assemble your
"hello world" example:

[chuck@heimdall hla]$ hla -v hw
HLA (High Level Assembler)
Released to the public domain by Randall Hyde.
Version Version 1.43 build 7563 (prototype)
ELF output
Using GAS assembler
GAS output

Files:
1: hw.hla

Compiling 'hw.hla' to 'hw.asm'
using command line [hlaparse -v -sg "hw.hla"]
HLA (High Level Assembler) Parser
Released to the public domain by Randall Hyde.
Version Version 1.43 build 7563 (prototype)
File: hw.hla
Output Path: ""

Compiling "hw.hla" to "hw.asm"
Error in file "/home/chuck/development/usr/hla/include/stdout.hhf" at line 639
[errid:1457/hla.flx]:
Macro called in file "hw.hla" at line 9
stdout.put: Unknown data type ("Hello, World of Assembly Language":string).
Near: << ) >>

Error in file "/home/chuck/development/usr/hla/include/stdout.hhf" at line 639
[errid:1457/hla.flx]:
Macro called in file "hw.hla" at line 9
stdout.put: Unknown data type (#13 #10:string).
Near: << ) >>

randall hyde

Okay, I will look at this sometime this afternoon and see if
I can duplicate the problem.
cheers,
Randy Hyde

randall hyde

That problem was fixed in a later version of HLA.
There was a problem with one of the header files in
the HLA standard library that got fixed. Somewhere
between HLA v1.52 and HLA v1.54 I got around to
merging the two sets of library routines so that there
was only one set of includes and one set of library routines.
This eliminated the "duplicate code, duplicate bugs, fixed
in only one location" problem.
Sorry.
Randy Hyde

charles a. crayne

On Sat, 09 Aug 2003 15:42:02 GMT


:That problem was fixed in a later version of HLA.
:There was a problem with one of the header files in
:the HLA standard library that got fixed. Somewhere
:between HLA v1.52 and HLA v1.54 I got around to
:merging the two sets of library routines so that there
:was only one set of includes and one set of library routines.
:This eliminated the "duplicate code, duplicate bugs, fixed
:in only one location" problem.

I am certainly pleased to hear that the problem has been fixed. However, that
raises the question of why I (and presumably Richart Hunt) am getting back level
code from the 1_54* tarball files. And, that being the case, where I can
download the true version 1.54 files.

-- Chuck

charles a. crayne

On Sat, 9 Aug 2003 11:53:27 -0700


:I am certainly pleased to hear that the problem has been fixed. However, that
:raises the question of why I (and presumably Richart Hunt) am getting back
:level code from the 1_54* tarball files. And, that being the case, where I can
:download the true version 1.54 files.

Here is an update on both problems:

The version which identifies itself as 1.43, and has the string problem, is the
one I build from 1_54hlasrc.tar.gz. The pre-compiled version from 1_54hla.tar.gz
identifies itself as Version 1.52 build 8171 (prototype),
and does not have the string problem, but does segfault on the "bounds" example
program at L340_handleSegV__hla_+6 mov 0x44(%eax),%eax because eax == 0, which
means that the stack is not properly set up at the point.

However, since you may have already fixed this problem, I do not want to spend
any more time on it until you confirm that I have the latest code.

-- Chuck