Discussion:
Seg fault with hla 1.99 on Fedora 8 linux
(too old to reply)
DaveR
2008-02-25 21:18:12 UTC
Permalink
Hi

I'm just starting out trying to learn assembler, using HLA and the
"Art of Assembler". I am having problems executing very simple demo
programs.

A hello world program works, however as soon as I introduce a
variable, I get a segfault. I have given a working and broken example
below.

Apologies if I have done something stupid(!) , but any help would be
appreciated. Please let me know if you need anymore information to
help...

Kind Regards
David

[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ uname -a
Linux beechwood.home 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST
2008 i686 i686 i386 GNU/Linux

====WORKING=====

[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ more HelloWorld.hla
program helloWorld;
#include( "stdlib.hhf" );

begin helloWorld;

stdout.put( "Hello, World of Assembly Language", nl );

end helloWorld;
[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -v HelloWorld.hla
HLA (High Level Assembler)
Use '-license' to see licensing information.
Version Version 1.99 build 12923 (prototype)
ELF output
OBJ output using internal FASM back-end
-test active

HLA Lib Path: /home/david/local/hla/hlalib/hlalib.a
HLA include path: /home/david/local/hla/include
HLA temp path:
Files:
1: HelloWorld.hla

Compiling 'HelloWorld.hla' to 'HelloWorld.o'
using command line:
[hlaparse -level=high -v -sf -celf -test "HelloWorld.hla"]

----------------------
HLA (High Level Assembler) Parser
use '-license' to view license information
Version Version 1.99 build 12923 (prototype)
-t active
File: HelloWorld.hla
Output Path: ""
Language Level: high

Compiling "HelloWorld.hla" to "HelloWorld.o"
Compilation complete, 14837 lines, 0.214 seconds, 69332 lines/
second
Using flat assembler version C1.66
3 passes, 1499 bytes.
----------------------
Linking via [ld -o "HelloWorld" "HelloWorld.o" "/home/david/local/
hla/hlalib/hlalib.a"]
[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./HelloWorld
Hello, World of Assembly Language

====BROKEN=====

[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ more
HelloWorldWithVar.hla
program helloWorld;
#include( "stdlib.hhf" );

static
InitDemo: int32 := 5;

begin helloWorld;

stdout.put( "Hello, World of Assembly Language", nl );
stdout.put( "InitDemo's value is ", InitDemo, nl );

end helloWorld;
[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -v
HelloWorldWithVar.hla
HLA (High Level Assembler)
Use '-license' to see licensing information.
Version Version 1.99 build 12923 (prototype)
ELF output
OBJ output using internal FASM back-end
-test active

HLA Lib Path: /home/david/local/hla/hlalib/hlalib.a
HLA include path: /home/david/local/hla/include
HLA temp path:
Files:
1: HelloWorldWithVar.hla

Compiling 'HelloWorldWithVar.hla' to 'HelloWorldWithVar.o'
using command line:
[hlaparse -level=high -v -sf -celf -test "HelloWorldWithVar.hla"]

----------------------
HLA (High Level Assembler) Parser
use '-license' to view license information
Version Version 1.99 build 12923 (prototype)
-t active
File: HelloWorldWithVar.hla
Output Path: ""
Language Level: high

Compiling "HelloWorldWithVar.hla" to "HelloWorldWithVar.o"
Compilation complete, 15683 lines, 0.223 seconds, 70327 lines/
second
Using flat assembler version C1.66
3 passes, 1644 bytes.
----------------------
Linking via [ld -o "HelloWorldWithVar" "HelloWorldWithVar.o" "/
home/david/local/hla/hlalib/hlalib.a"]
[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./HelloWorldWithVar
Hello, World of Assembly Language
InitDemo's value is Segmentation fault
nbaker2328
2008-02-25 22:20:57 UTC
Permalink
Post by DaveR
Hi
I'm just starting out trying to learn assembler, using HLA and the
"Art of Assembler". I am having problems executing very simple demo
programs.
A hello world program works, however as soon as I introduce a
variable, I get a segfault. I have given a working and broken example
below.
Apologies if I have done something stupid(!) , but any help would be
appreciated. Please let me know if you need anymore information to
help...
Kind Regards
David
Linux beechwood.home 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST
2008 i686 i686 i386 GNU/Linux
====WORKING=====
program helloWorld;
#include( "stdlib.hhf" );
begin helloWorld;
stdout.put( "Hello, World of Assembly Language", nl );
end helloWorld;
HLA (High Level Assembler)
Use '-license' to see licensing information.
Version Version 1.99 build 12923 (prototype)
ELF output
OBJ output using internal FASM back-end
-test active
HLA Lib Path: /home/david/local/hla/hlalib/hlalib.a
HLA include path: /home/david/local/hla/include
1: HelloWorld.hla
Compiling 'HelloWorld.hla' to 'HelloWorld.o'
[hlaparse -level=high -v -sf -celf -test "HelloWorld.hla"]
----------------------
HLA (High Level Assembler) Parser
use '-license' to view license information
Version Version 1.99 build 12923 (prototype)
-t active
File: HelloWorld.hla
Output Path: ""
Language Level: high
Compiling "HelloWorld.hla" to "HelloWorld.o"
Compilation complete, 14837 lines, 0.214 seconds, 69332 lines/
second
Using flat assembler version C1.66
3 passes, 1499 bytes.
----------------------
Linking via [ld -o "HelloWorld" "HelloWorld.o" "/home/david/local/
hla/hlalib/hlalib.a"]
Hello, World of Assembly Language
====BROKEN=====
HelloWorldWithVar.hla
program helloWorld;
#include( "stdlib.hhf" );
static
InitDemo: int32 := 5;
begin helloWorld;
stdout.put( "Hello, World of Assembly Language", nl );
stdout.put( "InitDemo's value is ", InitDemo, nl );
end helloWorld;
HelloWorldWithVar.hla
HLA (High Level Assembler)
Use '-license' to see licensing information.
Version Version 1.99 build 12923 (prototype)
ELF output
OBJ output using internal FASM back-end
-test active
HLA Lib Path: /home/david/local/hla/hlalib/hlalib.a
HLA include path: /home/david/local/hla/include
1: HelloWorldWithVar.hla
Compiling 'HelloWorldWithVar.hla' to 'HelloWorldWithVar.o'
[hlaparse -level=high -v -sf -celf -test "HelloWorldWithVar.hla"]
----------------------
HLA (High Level Assembler) Parser
use '-license' to view license information
Version Version 1.99 build 12923 (prototype)
-t active
File: HelloWorldWithVar.hla
Output Path: ""
Language Level: high
Compiling "HelloWorldWithVar.hla" to "HelloWorldWithVar.o"
Compilation complete, 15683 lines, 0.223 seconds, 70327 lines/
second
Using flat assembler version C1.66
3 passes, 1644 bytes.
----------------------
Linking via [ld -o "HelloWorldWithVar" "HelloWorldWithVar.o" "/
home/david/local/hla/hlalib/hlalib.a"]
Hello, World of Assembly Language
InitDemo's value is Segmentation fault
Just tried it with v1.97 and it worked without producing a seg-fault.
So this is a bug that was introduced sometime between then and v1.99!

Nathan.
DaveR
2008-02-25 23:11:30 UTC
Permalink
Thanks for that - is there a link to v1.97 , so that I can download it
and try it on my machine?

I look for historical versions on http://webster.cs.ucr.edu and
couldn't find any...

Regards
David
nbaker2328
2008-02-26 02:23:49 UTC
Permalink
Post by DaveR
Thanks for that - is there a link to v1.97 , so that I can download it
and try it on my machine?
I look for historical versions onhttp://webster.cs.ucr.eduand
couldn't find any...
You can typically locate historical versions by editing the number in
the URL:

http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.97/hla.linux.tar.gz

Nathan.
Frank Kotler
2008-02-26 01:06:44 UTC
Permalink
DaveR wrote:

...
Post by DaveR
Version Version 1.99 build 12923 (prototype)
This is really weird! I just now unloaded 1.99... and it's showing build
12922!

This works fine with your test program! So what's build 12923??? You
showing that build, Nathan?

You might try downloading/installing 1.99 again, or I've stuck 1.97 here:

http://mysite.verizon.net/fbkotler/hla-1.97.tar.gz

Grab it quick, it won't be there long.

(I suggest adding version numbers to the filenames you download from
Webster - for exactly this situation! :)

Good hLuck,
Frank
nbaker2328
2008-02-26 02:32:17 UTC
Permalink
Post by Frank Kotler
...
Post by DaveR
Version Version 1.99 build 12923 (prototype)
This is really weird! I just now unloaded 1.99... and it's showing build
12922!
Based on experience, this *probably* means that he actually has 1.100
(which is "reporting" to be 1.99) and this means that the StdLib
version is 3.x and so the bug is likely in the library. If so, we've
got a Bug Tracker: http://hla-stdlib.sourceforge.net/

Nathan.
DaveR
2008-02-26 09:36:42 UTC
Permalink
Hi

Thanks for all the help so far. I downloaded v1.97, and got a
slightly different effect:

[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./HelloWorldWithVar
Segmentation fault (core dumped)

Whereas with 1.99 I had:

[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./"HelloWorldWithVar"
Hello, World of Assembly Language
InitDemo's value is Segmentation fault (core dumped)



Is there anything else I can do to give you more information? I got a
core dump and loaded it into gdb. It didn't have much of a stack
trace , but here it is anyway:

For v1.97:

This GDB was configured as "i386-redhat-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

warning: core file may not match specified executable file.
(no debugging symbols found)
Core was generated by `./HelloWorldWithVar'.
Program terminated with signal 11, Segmentation fault.
#0 0x080481d5 in BuildExcepts__hla_ ()

For v1.99:

This GDB was configured as "i386-redhat-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".

warning: core file may not match specified executable file.
Core was generated by `./HelloWorldWithVar'.
Program terminated with signal 11, Segmentation fault.
#0 0x0804a02d in ?? ()

Kind Regards
David
nbaker2328
2008-02-27 01:09:25 UTC
Permalink
Post by DaveR
Hi
Thanks for all the help so far. I downloaded v1.97, and got a
Okay, Dave. It appears that HLA does not wear a Red Hat. I am pretty
confident that NASM does, so you might give it a try:

http://nasm.sourceforge.net/

Nathan.
http://del.icio.us/Evenbit/
Frank Kotler
2008-02-27 13:08:32 UTC
Permalink
Post by nbaker2328
Post by DaveR
Hi
Thanks for all the help so far. I downloaded v1.97, and got a
(the copy of 1.97 on my site is gone, BTW)

(You didn't, by any chance, overwrite /usr/hla/hlalib/hlalib.a with a
later version? That won't work!)
Post by nbaker2328
Okay, Dave. It appears that HLA does not wear a Red Hat. I am pretty
http://nasm.sourceforge.net/
If Nasm had a fan club, I'd be president (maybe "maximum leader", even),
so I won't argue with that suggestion. However... Nasm isn't going to
correspond well with AoA, which is what David would like to do...

If we're content to say "HLA doesn't wear a Red Hat", okay, but *I'd*
like to know *why*! Red Hat got a different instruction set??? I don't
think so!

Is fc 8 a 64-bit system? That would imply a different (G)as (not
relevant with this version of HLA?) and ld. I think ld complains loudly
in this case, and wouldn't link hw-without-int, either, but... The cure
for that, if we encounter it, is to add "-m elf_i386" to ld's command
line. I think HLA will do this... "-l" switch? (someone - not me - RTFM)

I don't think that's what's happening here. Why should HLA 1.97 produce
code that apparently segfaults at a different point than 1.99? The
"internal workings" of HLA differ, to be sure, but they should produce
*identical* code for "print a string, print an integer", I would think.
Possible change in the library code, of course, but I think version 1 of
the library's pretty stable at this point. Easy to check... I don't have
source for either of these versions installed right now... can look if
need be.

David has revealed himself as someone who knows what to do with a core
dump - something I have yet to learn (any tips?). My technique would be
to simply run it in gdb or ald or asmbug and see *where* the segfault
happened. Then I'd probably disassemble the executable with ndisasm to
see what HLA (and ld) really did... There are better ways, I'm sure...

Unless I'm mistaken, HLA using Gas as a back end put debugging symbols
in the executable(?), but HLA with "built-in Fasm" doesn't(?). If this
is so, perhaps we can ask HLA to output Gas code, and assemble and link
it "by hand". Might get more info out of gdb(?).

Since David's the one who's seeing the segfault, he's going to have to
help track it down. Not what I'd consider a "newbie exercise"! (but I
don't know how to read core dumps, so who's the "newbie"?) If you want
to mail me the failing executable(s) - fbkotler at verizon.net - I'll
look and see if I can see anything... No guarantees, of course.

I think I'm going to cc this to the !Yahoo! list, since Randy seems
(wisely, perhaps) to be giving usenet a rest. HLA is really "not my
bag", but I hate to see this left as "well, HLA doesn't work on Red
Hat". That's *really* not supposed to be the case!

Best,
Frank

(I can provide Nasm "print a string, print an int" examples that
"should" work on fc 8 - if it's 64-bit, Chuck can help... if you pefer
to go that route, but it ain't going to match AoA!)
Charles Crayne
2008-02-27 21:54:44 UTC
Permalink
On Wed, 27 Feb 2008 13:08:32 GMT
Post by Frank Kotler
If we're content to say "HLA doesn't wear a Red Hat", okay, but *I'd*
like to know *why*!
In a word, "packaging". The way Randy packages HLA for Linux makes
installation and upgrading very error prone. To begin with, as you have
previously noted, there is no version information in the distribution
file name. Next, the file untars to "usr/hla/...", which is not where
Linux expects to find executables, nor where non-rpm packages are
conventionally placed. In fact, since I prefer to have more than one
version installed, the executable on my system is:
"/home/chuck/install/hla-1.99/usr/hla/hla".

Randy's suggested solution for this problem is to modify the bash
initialization script to add the appropriate directory to $PATH, but
not only is this one more thing that the user has to remember to redo
when installing a new version, but makes running multiple versions
overly complicated. The same issues apply to the "HLALIB" and "HLAINC"
environment variables.
Post by Frank Kotler
Is fc 8 a 64-bit system?
There are both 32 and 64-bit versions, but the one David is running is
32-bit.
Post by Frank Kotler
The cure
for that, if we encounter it, is to add "-m elf_i386" to ld's command
line. I think HLA will do this... "-l" switch?
Yes, but the syntax is not well documented. '-l"m elf_i386"' works for
me. [By which I mean without the single quotes, but with the double
quotes. Note that there is no '-' in from of the 'm'].
--
Chuck
http://www.pacificsites.com/~ccrayne/charles.html
DaveR
2008-02-28 00:14:55 UTC
Permalink
Ok - thanks for the help guys! - I'll do my best. As you say, whilst
I'm happy to give NASM a go ( once I know a bit of assembler ) it
would be nice to get HLA working on my linux box, as it would make
following the book a lot easier ( BTW - I'm finding the book really
good and well layed out - only having done high level languages
before, this is all very enlightening... :-> )

Ok - now for the info that you wanted:

First - yes my install of FC8 is 32 bit.
Second - install paths. I have the following setup

HLA 1.99 installed in /home/david/local/hla1.99
HLA 1.97 installed in /home/david/local/hla1.97
A symlink from /home/david/local/hla -> hla1.9X (depending on which
version I'm testing)

and the following env vars set:
[***@beechwood:~/local ] $ env | grep hla
hlalib=/home/david/local/hla/hlalib/hlalib.a
hlainc=/home/david/local/hla/include
PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/david/local/
hla:/home/david/bin

Third - core dumps - I have done a little bit of C programming so have
some experience of gdb and examining core dumps, however , I'm not
really sure how this translates to assembler...

... Having just written the out the above, whilst trying to get some
more info I have now found a way to make it work , by switching the
assemblers

With internal FASM:

[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -xo
HelloWorldWithVar.hla
[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./HelloWorldWithVar
Hello, World of Assembly Language
InitDemo's value is Segmentation fault (core dumped)


With Gas:

[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -xg
HelloWorldWithVar.hla
[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./HelloWorldWithVar
Hello, World of Assembly Language
InitDemo's value is 5


Any thoughts on why this might be ( although now I can get on with
trying the examples :-> ... )?


Many thanks for all your help and advice!
Regards
David
Charles Crayne
2008-02-28 02:25:11 UTC
Permalink
On Wed, 27 Feb 2008 16:14:55 -0800 (PST)
Post by DaveR
Second - install paths. I have the following setup
I see two potential problems with your setup. The first is that there
are two executable modules for HLA, "hla" and "hlaparse". Although your
symlinks control which "hla" module is being called, both versions of
that module will invoke whichever version of "hlaparse" you last
copied into /home/david/local/hla. Likewise for "hlalib.a" and the HLA
include directory.

I have never [deliberately] tried mixing elements from different
releases, nor do I recall the issue being discussed, but I don't think
that it is a good idea. I just took a look at the four versions of
"hlalib.a" which I currently have installed, and no two of them are the
same size. So, if you really want to test different HLA versions, you
need to install each one in its own directory and modify the path to
both executables, and both environment variables, whenever you want to
switch versions.
--
Chuck
http://www.pacificsites.com/~ccrayne/charles.html
DaveR
2008-02-28 10:26:57 UTC
Permalink
Sorry - I did't make myself clear

/home/david/local/hla1.99 and /home/david/local/hla1.97

are directories each of which contains the full hla installation. So I
have

/home/david/local/hla1.99/hla
/home/david/local/hla1.99/hlaparse
/home/david/local/hla1.99/hlalib/hlalib.a
/home/david/local/hla1.99/include

and

/home/david/local/hla1.97/hla
/home/david/local/hla1.97/hlaparse
/home/david/local/hla1.97/hlalib/hlalib.a
/home/david/local/hla1.97/include

and the symlink is

[***@beechwood:~/local ] $ ls -l hla
lrwxrwxrwx 1 david users 7 2008-02-26 09:32 hla -> hla1.99/

The symbolic link just allows me to switch versions , as all my
paths and env variables just point to /home/david/local/hla/ I don't
copy anything into /home/david/local/hla/ , so I'm pretty confident
that I'm not using mixed versions.

Any thoughts on why switching backend assemblers makes a difference?

Regards
David
Charles Crayne
2008-02-28 23:12:48 UTC
Permalink
On Thu, 28 Feb 2008 02:26:57 -0800 (PST)
Post by DaveR
The symbolic link just allows me to switch versions , as all my
paths and env variables just point to /home/david/local/hla/ I don't
copy anything into /home/david/local/hla/ , so I'm pretty confident
that I'm not using mixed versions.
I hate to harp on this, but since both Frank and I have downloaded 1.99
and run your code without error, I would like to see the proverbial
'i's dotted and 't's crossed. Would you please post the results from
"which hlaparse"?
--
Chuck
http://www.pacificsites.com/~ccrayne/charles.html
DaveR
2008-02-28 23:25:38 UTC
Permalink
Hi Frank - looks like our post's crossed!

I'm pretty sure my setup's ok - but I've gone with the "vanilla" hla
setup to remove any doubt:

[***@beechwood:/usr/hla ] # ls -l /usr/hla/hla /usr/hla/hlaparse /usr/
hla/hlalib/hlalib.a
-rwxr-xr-x 1 root root 519176 2008-01-07 21:02 /usr/hla/hla
-rw-r--r-- 1 root root 1575420 2008-01-07 21:09 /usr/hla/hlalib/
hlalib.a
-rwxr-xr-x 1 root root 2191935 2008-01-07 21:02 /usr/hla/hlaparse

The file sizes ( and timestamps - ignoring timezones ) match, which
looks good.
Environment variables below:

[***@beechwood:~ ] $ env | grep hla
hlalib=/usr/hla/hlalib/hlalib.a
hlainc=/usr/hla/include
PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/hla:/home/
david/bin

And the switch assemblers test repeated:

[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ which hla
/usr/hla/hla
[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -xo
HelloWorldWithVar.hla
[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./HelloWorldWithVar
Hello, World of Assembly Language
InitDemo's value is Segmentation fault
[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -xg
HelloWorldWithVar.hla
[***@beechwood:~/local/AoA/Volume1/Ch02 ] $ ././HelloWorldWithVar
Hello, World of Assembly Language
InitDemo's value is 5

So I have uploaded the hla file and the output from both compiles to
http://hla.webhop.org/ for anyone who want a closer look.

Do you know the best way to raise this with Randy? Bug on
Sourceforge / email etc?

Back to the books now....

Kind Regards
David
nbaker2328
2008-02-29 03:51:09 UTC
Permalink
Post by DaveR
Hi Frank - looks like our post's crossed!
I'm pretty sure my setup's ok - but I've gone with the "vanilla" hla
hla/hlalib/hlalib.a
-rwxr-xr-x 1 root root 519176 2008-01-07 21:02 /usr/hla/hla
-rw-r--r-- 1 root root 1575420 2008-01-07 21:09 /usr/hla/hlalib/
hlalib.a
-rwxr-xr-x 1 root root 2191935 2008-01-07 21:02 /usr/hla/hlaparse
Why are you running as root user???
Post by DaveR
Do you know the best way to raise this with Randy? Bug on
Sourceforge / email etc?
Randall Hyde <randyhyde (at) earthlink (dot) net>

Bug reports for v1.x can be filed at:
http://sourceforge.net/tracker/?group_id=215104&atid=1032333

You may also want to test v1.101 to see if it still shows up there --
if so, then report the results here:
http://sourceforge.net/tracker/?group_id=165727&atid=836524

Nathan.
Frank Kotler
2008-02-29 05:59:51 UTC
Permalink
Post by DaveR
Hi Frank - looks like our post's crossed!
Yeah, it happens...
Post by DaveR
I'm pretty sure my setup's ok - but I've gone with the "vanilla" hla
Okay... FWIW, I tried it "your way" (more or less -
/home/fbk/usr/hla/lahdeedah", not "local") and it worked fine. Next
step, try putting hla and hlaparse someplace "normal"... haven't gotten
to trying that...
Post by DaveR
hla/hlalib/hlalib.a
-rwxr-xr-x 1 root root 519176 2008-01-07 21:02 /usr/hla/hla
-rw-r--r-- 1 root root 1575420 2008-01-07 21:09 /usr/hla/hlalib/
hlalib.a
-rwxr-xr-x 1 root root 2191935 2008-01-07 21:02 /usr/hla/hlaparse
The file sizes ( and timestamps - ignoring timezones ) match, which
looks good.
hlalib=/usr/hla/hlalib/hlalib.a
hlainc=/usr/hla/include
PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/hla:/home/
david/bin
/usr/hla/hla
HelloWorldWithVar.hla
Hello, World of Assembly Language
InitDemo's value is Segmentation fault
HelloWorldWithVar.hla
Hello, World of Assembly Language
InitDemo's value is 5
So I have uploaded the hla file and the output from both compiles to
http://hla.webhop.org/ for anyone who want a closer look.
Now we're cooking with Gas! :) Actually it's the Fasm version I'm
interested in. A preliminary analysis of your "Fasm" executable shows
that where we should be in CONV_I64TOBUF, we're in a block of zeros...
Go boom!

*Why* remains a mystery. My version of 1.99 reads *just* like your
original post, right up to "Version Version"... but my build number is
12922 and yours is 12923... weird... (I obtained 1.100 and verified that
it *doesn't* report 1.99 and build 12923, so that's not it...).

I linked your .o file "ld -o hwvar HelloWorldWithVar.o
/usr/hla/hlalib/hlalib.a"... and it worked perfectly.

Lemme see... Your library's corrupted. No, then it wouldn't work with
Gas, either.

Your ld is choking on something my ld likes. Something HLA gets right
with "-xg", but gets "wrong" with the internal Fasm (possibly only in
"build 12923"?). Improbable as that seems, I can't rule it out, and
can't think of anything else.

I'll see if I can get into your .o file, Fasm vs Gas, byte by byte, but
I probably won't spot anything...
Post by DaveR
Do you know the best way to raise this with Randy? Bug on
Sourceforge / email etc?
The bugtracker on SourceFrog would be great... but I think it's mostly
for the new library, and versions 1.100+ of HLA. Wouldn't hurt. Randy's
SF username is "rhydehla", and you can reach any SourceForge user at
"users.sf.net". (or randyhyde at earthlink dot net) I'll cc this to the
Yahoo group - where he *is* posting recently. You might want to join
that group anyway:

http://tech.groups.yahoo.com/group/aoaprogramming/

Thanks for posting those files - gives us something we can sink our
teeth into, even if the "why" isn't obvious - you're not dreamin', it
really does segfault, yet the .o file works okay here... Use "-xg" for
the examples, I guess...

Best,
Frank
Charles Crayne
2008-02-29 06:51:26 UTC
Permalink
On Fri, 29 Feb 2008 05:59:51 GMT
Post by Frank Kotler
A preliminary analysis of your "Fasm" executable shows
that where we should be in CONV_I64TOBUF, we're in a block of
zeros... Go boom!
Yes, I get the same results on my system, including getting the correct
results after local linking. The key to the is almost certainly the
12923 build, which neither of us has, nor knows where to find. Perhaps
Randy put up that build, found a problem with it, and reverted to 12922
-- and David was unlucky enough to download during that window.
--
Chuck
http://www.pacificsites.com/~ccrayne/charles.html
Frank Kotler
2008-03-13 21:32:15 UTC
Permalink
Post by Charles Crayne
On Fri, 29 Feb 2008 05:59:51 GMT
Post by Frank Kotler
A preliminary analysis of your "Fasm" executable shows
that where we should be in CONV_I64TOBUF, we're in a block of
zeros... Go boom!
Yes, I get the same results on my system, including getting the correct
results after local linking. The key to the is almost certainly the
12923 build, which neither of us has, nor knows where to find. Perhaps
Randy put up that build, found a problem with it, and reverted to 12922
-- and David was unlucky enough to download during that window.
Perhaps this is a stale question, but it's still "open" in my mind. Got
a reply from Randy on the Yahoo list...

---------------------------
Post by Charles Crayne
Post by Frank Kotler
In another issue entirely... probably a dead issue - the guy's either
got HLA working or has switched to Nasm - on c.l.a.x., a guy downloaded
HLA - Linux version 1.99 - and was seeing a "build 12923" instead of
12922 like I'm seeing. (worked with "hw" but "hw-with-integer" was
segfaulting). Was there a different build on Webster at one time,
or are
Post by Charles Crayne
Post by Frank Kotler
we hallucinating? (just to clear my mind...)
I'm pleased to see your progress on HLA - and the "interaction" of
users
Post by Charles Crayne
Post by Frank Kotler
with it. Going good!!!
I wouldn't be surprised to find that the build numbers for Linux, BSD,
and Win32 are different. OTOH, I doubt there would be a build difference
of only one for the same OS, even if I uploaded a new copy. So likely,
it was an OS difference.
The OS changed the build number???
No. But to build the version for a different OS requires a new build.
And *every* build changes the build number (that is, after all, the
purpose of the build number).
Post by Charles Crayne
I guess Nathan's right, then? HLA won't run on Red Hat?
I don't know. I haven't run Red Hat in years. I cannot imagine, however,
that it's an OS-related issue. More likely a memory configuration issue
that just happens to case HLA to fail on that particular system.
Post by Charles Crayne
Post by Frank Kotler
As for the segfault -- I'd look into it if I had more info -- and
time..... :-(
I'd look into it if I could reproduce it! The code works fine for me
http://hla.webhop.org/
The faulty one is full of zeros where there should be code! Not a
"subtle" bug!
Post by Frank Kotler
Someday, I'll go back to ALA and grab the post and see if I can make
anything of the problem.
Clax, not ala.
[section snipped due to discussion of moderation policy being off-topic
in a moderated NG]
Post by Charles Crayne
from c.l.a.x.
----------------------------
snipped.
[DaveR's original post]

Yeah, works fine for me on Suse. As I said, it's probably a memory
layout issue that just happened to tickle some bug in HLA. I suspect
you'll find the problem goes away in HLA v1.102, as I'm completely
rewriting the parser and code generator for the compiler.
hLater,
Randy Hyde
-------------------------

So there's the definitive answer from the author.
Post by Charles Crayne
So likely, it was an OS difference.
...
Post by Charles Crayne
I cannot imagine, however, that it's an OS-related issue.
One of those. :) (to be fair, those are out of context)

Randy disclaims responsibility for build 12923. You didn't build it
yourself, did you Dave? (still with us? probably not...) He said
"download", so I greatly doubt it...

Upgrading to the latest version, rather than chasing bugs in an old
version, is generally wise. In this case, version 1.99 is "frozen" -
exists for people who want it to exactly match The Book (like Dave!).
The new library (currently version 3.0, IIRC), introduces quite a few
changes (vastly improved code, IMHO, but "in progress"... "buggy", I
mean). So it won't exactly match The Book. Probably "close enough"(?).

I haven't gotten into the comparison between the "good" and "bad" object
files, except to note that the Gas output has debugging information, so
the comparison is not as simple as it might be. I need to learn the
nitty-gritty details of headers anyway... "some day". Don't hold your
breath.

Since debugging info makes gdb a whole lot friendlier, "-xg" may be a
better idea anyway...

Best,
Frank
nbaker2328
2008-02-29 00:50:12 UTC
Permalink
Post by Charles Crayne
I have never [deliberately] tried mixing elements from different
releases, nor do I recall the issue being discussed, but I don't think
that it is a good idea.
There is generally no problem resulting from mixing different library
releases with the compiler. It does, however, make things more
difficult when one mixes things and expects others to be able to do a
"remote diagnosis" but does not reveal all of the ingedients in his
special mix.

Nathan.
Frank Kotler
2008-02-28 10:47:59 UTC
Permalink
Post by DaveR
Ok - thanks for the help guys! - I'll do my best. As you say, whilst
I'm happy to give NASM a go ( once I know a bit of assembler ) it
would be nice to get HLA working on my linux box, as it would make
following the book a lot easier ( BTW - I'm finding the book really
good and well layed out - only having done high level languages
before, this is all very enlightening... :-> )
First - yes my install of FC8 is 32 bit.
Yeah... I'd have known that if I'd read your original post more carefully.
Post by DaveR
Second - install paths. I have the following setup
HLA 1.99 installed in /home/david/local/hla1.99
HLA 1.97 installed in /home/david/local/hla1.97
A symlink from /home/david/local/hla -> hla1.9X (depending on which
version I'm testing)
Chuck has pointed out some potential problems with this. Randy's
"packaging system" is not "the way you do it in Unix". A long time ago,
I tried installing HLA under /home/fbk, with the executables in /usr/bin
or /usr/local/bin... I *thought* I had path and environment variables
set "right" for what I was trying to do, but it behaved as if some
component were hard-coded into... ??? I forget what the "diagnostic"
was. Since then, I've done it "Randy's way" - as root, get into "/" and
"tar zxf /home/fbk/hla-1.99.tar.gz" (I add the version info when I
download it). (certain earlier versions, you had to be in "/usr", not
"/") This has worked well enough so I haven't gone back to trying it the
way I'd "like" to install it.
Post by DaveR
hlalib=/home/david/local/hla/hlalib/hlalib.a
hlainc=/home/david/local/hla/include
PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/david/local/
hla:/home/david/bin
This looks right... Chuck quotes these as "HLAINC" and "HLALIB" - lasi I
checked, they *had* to be lowercase - yet another "unusual" feature of
"Randy's system".

I really think this "ought" to work the way you're doing it, but if all
else fails, try it the "HLA way" and see if it helps...
Post by DaveR
Third - core dumps - I have done a little bit of C programming so have
some experience of gdb and examining core dumps, however , I'm not
really sure how this translates to assembler...
Well, best thing is to avoid 'em, I guess... Still on my "TODO" list to
learn more about this...
Post by DaveR
... Having just written the out the above, whilst trying to get some
more info I have now found a way to make it work , by switching the
assemblers
HelloWorldWithVar.hla
Hello, World of Assembly Language
InitDemo's value is Segmentation fault (core dumped)
HelloWorldWithVar.hla
Hello, World of Assembly Language
InitDemo's value is 5
Any thoughts on why this might be ( although now I can get on with
trying the examples :-> ... )?
On the face of it, you've discovered a bug in the code generation of
"internal Fasm". But... the funny build number, and the fact that HLA
seems to work "as-is" for other people makes me suspect some subtle
"mismatch" in the way you've got it installed. I'd expect a "diagnostic"
rather than a faulting executable - this is a "bug" in HLA, perhaps, but
not too unexpected (if that's what's happening).

At least now you've got two executables to compare - yourself or send
'em to someone - Randy, if it's really a bug in HLA. And you've got a
workaround so you can do the examples...

But I'm really puzzled by that build number... Here's what's working for
me (slightly pruned) - this is 1.99 (let's concentrate on that):

/usr/hla:
-rwxr-xr-x 1 root root 519176 2008-01-07 16:02 hla*
-rwxr-xr-x 1 root root 2191935 2008-01-07 16:02 hlaparse*

/usr/hla/hlalib:
-rw-r--r-- 1 root root 1575420 2008-01-07 16:09 hlalib.a

Sizes match, at least?

Nathan's suggestion that the build number suggests 1.10x masquerading as
1.99 is worrisome. HLA is in "version number hell" right now, so mixups
(not necessarily yours) are possible...
Post by DaveR
Many thanks for all your help and advice!
No problem. Some people do crossword puzzles. :) If you get good at
this, we'll be coming to *you* for help and advice!

Best,
Frank
nbaker2328
2008-02-29 00:43:23 UTC
Permalink
Post by Frank Kotler
Post by nbaker2328
Okay, Dave. It appears that HLA does not wear a Red Hat. I am pretty
http://nasm.sourceforge.net/
If Nasm had a fan club, I'd be president (maybe "maximum leader", even),
so I won't argue with that suggestion. However... Nasm isn't going to
correspond well with AoA, which is what David would like to do...
Nasm is an assembler isn't it? AoA teaches assembly, right?

It should be possible to convert most of the AoA examples to Nasm
source using the C library for the I/O stuff. Alternatively, one
could convert them directly to C code using inline assembly.

Nathan.
Frank Kotler
2008-02-29 08:52:26 UTC
Permalink
Post by nbaker2328
Post by Frank Kotler
Post by nbaker2328
Okay, Dave. It appears that HLA does not wear a Red Hat. I am pretty
http://nasm.sourceforge.net/
If Nasm had a fan club, I'd be president (maybe "maximum leader", even),
so I won't argue with that suggestion. However... Nasm isn't going to
correspond well with AoA, which is what David would like to do...
Nasm is an assembler isn't it? AoA teaches assembly, right?
Dunno. Nasm is an assembler. Nasm won't assemble what AoA teaches.
Conclusion?
Post by nbaker2328
It should be possible to convert most of the AoA examples to Nasm
source using the C library for the I/O stuff. Alternatively, one
could convert them directly to C code using inline assembly.
Sure, "echo the answer is 5" is possible, too. Or "just call printf". Or
we could use the HLA library (stepping through it, Wolfgang's right -
detoured) from Nasm, too, or vid's fasmlib (which, despite the name, is
for Nasm too). Maybe David doesn't care too much if it runs on
Windows... we could do it with Jeff Owens' lib, or we could do it
without no steenking library.

Start with something simple... Linux only. We can add ExitProcess and
WriteFile later...

Best,
Frank

; nasm -f elf hwint.asm
; ld -o hwint hwint.o

global _start

section .data

hiya db "Hello, World of (real) Assembly Language!", 10
; "$", in this context, means "here", the current offset
; in the file, so this calculation counts characters.
hiya_len equ $ - hiya

; ans db "InitDemo's value is Segmentation Fault", 10
; naw, that's *too* simple
ans db "InitDemo's value is "
ans_len equ $ - ans

InitDemo dd 5

section .text
_start:
mov ecx, hiya
mov edx, hiya_len
call write_stdout

mov ecx, ans
mov edx, ans_len
call write_stdout

mov eax, [InitDemo]
call showeaxd

call newline
xor eax, eax ; claim "no error".

exit:
mov ebx, eax ; error/return code in ebx (bl, actually)
mov eax, 1 ; __NR_exit
int 80h
;-----------------------

;---------------------------------
showeaxd:
pusha ; save caller's regs

sub esp, 10h ; make buffer on stack
lea ecx, [esp + 10h] ; start at "end" of buffer
mov ebx, 10 ; for decimal, divide by 10
xor esi, esi ; length counter
.top:
dec ecx ; work towards "front" of buffer
xor edx, edx ; "div" works with edx:eax!
div ebx ; quotient in eax, remainder in edx
add dl, '0' ; convert number to ascii char
mov [ecx], dl ; store it
inc esi ; count it
or eax, eax ; quotient zero?
jnz .top ; do more

mov edx, esi ; length in edx
call write_stdout ; print it

add esp, 10h ; free the buffer

popa ; restore caller's regs
ret
;---------------------------------

;-------------------
newline:
pusha
push 10 ; linefeed
mov ecx, esp ; stack is the buffer
mov edx, 1 ; just one
call write_stdout
add esp, 4 ; free buffer
popa
ret
;------------------

;------------------
write_stdout:
mov ebx, 1 ; STDOUT
mov eax, 4 ; __NR_write
int 80h
ret
;-------------------
Herbert Kleebauer
2008-02-29 13:25:43 UTC
Permalink
Post by Frank Kotler
Start with something simple... Linux only. We can add ExitProcess and
WriteFile later...
Best,
Frank
; nasm -f elf hwint.asm
; ld -o hwint hwint.o
Couldn't resist and had to convert your example to a more readable NASM
syntax. It's still not what I would call an usable syntax for writing
programs, but anything is better than Intel syntax:


;===========================================================================
; nasm -O99 -f bin -o hwint hwint.asm
%include "mac.inc" ; ftp://137.193.64.130/pub/assembler/xlinux.zip
;===========================================================================
seg 32
orig equ $08048000
code_addr equ orig
code_offset equ 0
section .text vstart=code_addr
;--------------------------- ELF header -----------------------------------
dc.l $464c457f,$00010101,0,0,$00030002,1,main,$34,0,0,$00200034,2,0
dc.l 1,code_offset,code_addr,code_addr,code_filez,code_memsz,5,4096
dc.l 1,data_offset,data_addr,data_addr,data_filez,data_memsz,6,4096
;--------------------------- code ------------------------------------------


main: move.l hiya,r2
move.l hiya_len,r1
bsr.l write_stdout

move.l ans,r2
move.l ans_len,r1
bsr.l write_stdout

move.l [InitDemo],r0
bsr.l showeaxd

bsr.l newline
eor.l r0,r0 ; claim "no error".

exit: move.l r0,r3 ; error/return code in ebx (bl, actually)
move.l 1,r0 ; __NR_exit
trap $80


showeaxd:
movem.l r0-r7,-[sp] ; save caller's regs

sub.l $10,r7 ; make buffer on stack
lea.l [r7+$10],r2 ; start at "end" of buffer
move.l 10,r3 ; for decimal, divide by 10
eor.l r5,r5 ; length counter

.top: dec.l r2 ; work towards "front" of buffer
eor.l r1,r1 ; "div" works with edx:eax!
divu.l r3,r1|r0 ; quotient in eax, remainder in edx
add.b '0',r1 ; convert number to ascii char
move.b r1,[r2.l] ; store it
inc.l r5 ; count it
or.l r0,r0 ; quotient zero?
bne.b .top ; do more

move.l r5,r1 ; length in edx
bsr.l write_stdout ; print it

add.l $10,r7 ; free the buffer

movem.l [sp]+,r0-r7 ; restore caller's regs
rts.l

newline:movem.l r0-r7,-[sp]
moveq.l 10,-[sp] ; linefeed
move.l r7,r2 ; stack is the buffer
move.l 1,r1 ; just one
bsr.l write_stdout
addq.l 4,r7 ; free buffer
movem.l [sp]+,r0-r7
rts.l

write_stdout:
move.l 1,r3 ; STDOUT
move.l 4,r0 ; __NR_write
trap $80
rts.l

;===========================================================================

;--------------------------- constant data ---------------------------------
hiya: dc.b "Hello, World of (real) Assembly Language!", 10
hiya_len equ $-hiya

ans: dc.b "InitDemo's value is "
ans_len equ $-ans

InitDemo: dc.l 5
;---------------------------------------------------------------------------

align 4
code_memsz equ $-$$
code_filez equ code_memsz
data_addr equ (orig+code_memsz+4095)/4096*4096 + (code_filez % 4096)
data_offset equ code_filez
section .data vstart=data_addr

;--------------------------- initialized data ------------------------------

;---------------------------------------------------------------------------

idat_memsz equ $-$$
bss_addr equ data_addr+ ($-$$)
section .bss vstart=bss_addr

;--------------------------- uninitialized data ----------------------------

;---------------------------------------------------------------------------

udat_memsz equ $-$$
data_memsz equ idat_memsz + udat_memsz
data_filez equ idat_memsz
;===========================================================================
nbaker2328
2008-03-01 06:43:55 UTC
Permalink
Post by Frank Kotler
Post by nbaker2328
Nasm is an assembler isn't it? AoA teaches assembly, right?
Dunno. Nasm is an assembler. Nasm won't assemble what AoA teaches.
Conclusion?
One should not use Nasm to learn assembly! :)
Post by Frank Kotler
; nasm -f elf hwint.asm
; ld -o hwint hwint.o
Your code assumes that "AoA student" knows what "inc, call, jnz, xor,
and etc." is this early in the book. A few chapters in, it covers
some basic instructions. My conversion of it suffers the same
problem. Guess it'd be best to stuff some macros away into an include
file...

Nathan.

Original HLA example:

program DemoMOVaddSUB;



#include( "stdlib.hhf" );



static



i8: int8 := -8;

i16: int16 := -16;

i32: int32 := -32;



begin DemoMOVaddSUB;



// First, print the initial values

// of our variables.



stdout.put



(



nl,



"Initialized values: i8=", i8,



", i16=", i16,



", i32=", i32,



nl



);



// Compute the absolute value of the

// three different variables and

// print the result.

// Note, since all the numbers are

// negative, we have to negate them.

// Using only the MOV, ADD, and SUB

// instruction, we can negate a value

// by subtracting it from zero.



mov( 0, al ); // Compute i8 := -i8;



sub( i8, al );



mov( al, i8 );







mov( 0, ax ); // Compute i16 := -i16;



sub( i16, ax );



mov( ax, i16 );







mov( 0, eax ); // Compute i32 := -i32;



sub( i32, eax );



mov( eax, i32 );




// Display the absolute values:





stdout.put



(



nl,



"After negation: i8=", i8,



", i16=", i16,



", i32=", i32,



nl



);





// Demonstrate ADD and constant-to-memory

// operations:





add( 32323200, i32 );



stdout.put( nl, "After ADD: i32=", i32, nl );







end DemoMOVaddSUB;



; The demoMOVaddSUB example converted from AoA.
;
; nasm -f elf -o demo.o demo.asm
; gcc -o demo demo.o

section .data

i8: db -8
i16: dw -16
i32: dd -32
initVal: db ' Initialized values:', 10, 0
negVal: db ' After negation:', 10, 0
addVal: db ' After addition:', 10, 0
str8: db ' i8 = %d', 10, 0
str16: db ' i16 = %d', 10, 0
str32: db ' i32 = %d', 10, 0

section .text

global main
extern printf

main:

; First, print the initial values

; of our variables.


lea eax, [initVal] ; or use 'mov eax, initVal'
push eax
call printf
add esp, 4

movsx eax, BYTE [i8] ; sign-extended mov
push eax
lea eax, [str8]
push eax
call printf
add esp, 8

movsx eax, WORD [i16] ; sign-extended mov
push eax
lea eax, [str16]
push eax
call printf
add esp, 8

mov eax, LONG [i32] ; a regular mov
push eax
lea eax, [str32]
push eax
call printf
add esp, 8

; Compute the absolute value of the

; three different variables and

; print the result.

; Note, since all the numbers are

; negative, we have to negate them.

; Using only the MOV, ADD, and SUB

; instruction, we can negate a value

; by subtracting it from zero.


mov al, 0
sub al, BYTE [i8]
mov BYTE [i8], al

mov ax, 0
sub ax, WORD [i16]
mov WORD [i16], ax

mov eax, 0
sub eax, LONG [i32]
mov LONG [i32], eax

; Display the absolute values:


lea eax, [negVal]
push eax
call printf
add esp, 4

movsx eax, BYTE [i8]
push eax
lea eax, [str8]
push eax
call printf
add esp, 8

movsx eax, WORD [i16]
push eax
lea eax, [str16]
push eax
call printf
add esp, 8

mov eax, LONG [i32]
push eax
lea eax, [str32]
push eax
call printf
add esp, 8

; Demonstrate ADD and constant-to-memory

; operations:


add LONG [i32], 32323200

lea eax, [addVal]
push eax
call printf
add esp, 4

mov eax, LONG [i32]
push eax
lea eax, [str32]
push eax
call printf
add esp, 8

ret
nbaker2328
2008-03-01 10:29:04 UTC
Permalink
        lea eax, [initVal] ; or use 'mov eax, initVal'
        push eax
Or just 'push initVal' ...talking about detours... :)
        call printf
        add esp, 4
        movsx eax, BYTE [i8] ; sign-extended mov
        push eax
        lea eax, [str8]
        push eax
        call printf
        add esp, 8
Or ( for more clarity ) something like...

sub esp, 8
mov al, BYTE [i8]
movsx [esp+8], al
mov [esp+4], str8
call printf
add esp, 8

Nathan.
nbaker2328
2008-03-01 18:55:15 UTC
Permalink
Post by nbaker2328
sub esp, 8
mov al, BYTE [i8]
movsx [esp+8], al
mov [esp+4], str8
call printf
add esp, 8
To correct that:

sub esp, 8
movsx eax, BYTE [i8]
mov ebx, str8
mov [esp+4], eax
mov [esp], ebx
call printf
add esp, 8

Nathan.
Frank Kotler
2008-03-01 20:36:34 UTC
Permalink
Post by nbaker2328
Post by Frank Kotler
Post by nbaker2328
Nasm is an assembler isn't it? AoA teaches assembly, right?
Dunno. Nasm is an assembler. Nasm won't assemble what AoA teaches.
Conclusion?
One should not use Nasm to learn assembly! :)
Perhaps. When using Nasm, the segfaults are *my* fault. This might tend
to demoralize the beginner...
Post by nbaker2328
Post by Frank Kotler
; nasm -f elf hwint.asm
; ld -o hwint hwint.o
Your code assumes that "AoA student" knows what "inc, call, jnz, xor,
and etc."
Yes. My mistake - I should have left that until after they've learned
assembly language... :)

My "Clueless Newbie's Guide to Hello World in Nasm" once had a "chapter
two", in which every "mov", etc. was a link to the instruction in the
Nasm manual, and every "int" was a link to RBIL. Then Nasm and RBIL both
updated, breaking all my links...
Post by nbaker2328
is this early in the book. A few chapters in, it covers
some basic instructions.
Yeah... I did not select the example. In "my book" (which I am *far* to
lazy to ever write), this would be "example13" or so.
Post by nbaker2328
My conversion of it suffers the same
problem.
It's a paradox. You can *tell* 'em about "mov", but if you want to
*show* 'em "mov", you need a lot more than "mov" to have anything to show!
Post by nbaker2328
Guess it'd be best to stuff some macros away into an include
file...
%include "you_are_not_expected_to_understand_this.inc"

Yeah, that's one common approach. It may be the best one, but it kind of
grates on me. I'd start with:

global _start

section .text
_start:

mov bl, 42
mov eax, 1
int 80h

and work up from there (Jonathan Bartlett's PGU, for example). But AoA
is aimed at a "course" which lasts some number of weeks that will fit in
4 bits. This changes the picture! In particular, if the course is
supposed to be "Computer Architecture and Assembly Language", you might
like to be able to write an assembly language program that explored some
computer architecture... This is where "the_hard_parts.inc" comes in.
"the_OS_specific_parts.inc" has value on its own, of course.

Some very minor nits...
Post by nbaker2328
lea eax, [initVal] ; or use 'mov eax, initVal'
Might want to leave "lea" until we need it. "tell me the address of the
object whose address is initVal" always seems like overkill to me...
Post by nbaker2328
push eax
push initVal ?
Post by nbaker2328
call printf
add esp, 4
I guess "add" isn't too mysterious to spring on the unsuspecting newbie. :)
Post by nbaker2328
movsx eax, BYTE [i8] ; sign-extended mov
I was hoping we could ignore "sign" for now. :) "sub" kinda requires it,
I guess. In practice, I rarely find the need to display a negative number...
Post by nbaker2328
; Compute the absolute value of the
Not really...
Post by nbaker2328
add LONG [i32], 32323200
Nasm likes "LONG"? So it does! We live and learn. I'd have used "dword"...

Nits aside, nice example. I guess to "port" it to Windows, we'd want to
add "--prefix _" to nasm's command line. Paul Carter's examples use a
"-d ELF_TYPE" on the command line to remove underscores for ELF... And
he "hides" the use of printf (etc.). His "first.asm" inputs two numbers
from the user, adds them, and prints the result. I simplified this to be
like "HelloWorldWithVar", just to see what it would look like using this
approach...

Best,
Frank

; file: hwint.asm
; This program prints a message and a number.
;
; Cribbed from Dr. Paul Carter's "first.asm", mostly
; http://www.drpaulcarter.com/pcasm
;
; To create executable:
;
; These assume that asm_io.o has been built. If not:
; nasm -f <your output format> -d <YOUR_TYPE> asm_io.asm
;
; Using djgpp:
; nasm -f coff -d COFF_TYPE hwint.asm
; gcc -o hwint hwint.o driver.c asm_io.o
;
; Using Borland C/C++
; nasm -f obj -d OBJ_TYPE hwint.asm
; bcc32 hwint.obj driver.c asm_io.obj
;
; Using Linux: (only one I've tested)
; nasm -f elf -d ELF_TYPE hwint.asm
; gcc -o hwint hwint.o driver.c asm_io.o
;
; Mac? Why not?
; nasm -f macho - d ELF_TYPE(??? no underscores?) hwint.asm
; gcc(???) -o hwint hwint.o driver.c asm_io.o
;

;
; this provides the requisite "extern" declarations,
; and some (neat!) macros that we don't use here
;
%include "asm_io.inc"

;
; initialized data is put in the .data segment
;
segment .data
;
; These labels refer to strings used for output
;

message db "Hello, World of assembly language (and C)", 10, 0
answer db "InitDemo's value is ", 0

;
; An integer variable.
;

InitDemo dd 5

;
; code is put in the .text segment
;
segment .text
global asm_main ; make ourselves known to the linker
asm_main:
enter 0,0 ; setup routine
pusha

mov eax, message ; print out prompt
call print_string

mov eax, answer
call print_string

mov eax, [InitDemo]
call print_int ; print out InitDemo

call print_nl ; print new-line

popa
mov eax, 0 ; return back to C
leave
ret
nbaker2328
2008-03-03 02:22:15 UTC
Permalink
Post by Frank Kotler
Post by nbaker2328
Post by Frank Kotler
Post by nbaker2328
Nasm is an assembler isn't it? AoA teaches assembly, right?
Dunno. Nasm is an assembler. Nasm won't assemble what AoA teaches.
Conclusion?
One should not use Nasm to learn assembly! :)
Perhaps. When using Nasm, the segfaults are *my* fault. This might tend
to demoralize the beginner...
That is a deep and sobering epiphany.
Post by Frank Kotler
Post by nbaker2328
Post by Frank Kotler
; nasm -f elf hwint.asm
; ld -o hwint hwint.o
Your code assumes that "AoA student" knows what "inc, call, jnz, xor,
and etc."
Yes. My mistake - I should have left that until after they've learned
assembly language... :)
There is always room for a "Catch-22" no matter what the goal is.
Building a staircase requires one to follow a series of steps in order
to construct a series of steps. :)
Post by Frank Kotler
My "Clueless Newbie's Guide to Hello World in Nasm" once had a "chapter
two", in which every "mov", etc. was a link to the instruction in the
Nasm manual, and every "int" was a link to RBIL. Then Nasm and RBIL both
updated, breaking all my links...
Interesting solution. How did the readers react to it?
Post by Frank Kotler
and work up from there (Jonathan Bartlett's PGU, for example). But AoA
is aimed at a "course" which lasts some number of weeks that will fit in
4 bits. This changes the picture! In particular, if the course is
supposed to be "Computer Architecture and Assembly Language", you might
like to be able to write an assembly language program that explored some
computer architecture... This is where "the_hard_parts.inc" comes in.
"the_OS_specific_parts.inc" has value on its own, of course.
Some taste of OS-interfacing is desirable, but I'm not sure I agree
that it should be present throughout the main course.
Post by Frank Kotler
Post by nbaker2328
; Compute the absolute value of the
Not really...
I noticed that too. But it is factual for *that* specific instance of
data.
Post by Frank Kotler
message db "Hello, World of assembly language (and C)", 10, 0
Well, it is ALWAYS going to be "(and _something_)" no matter how you
approach it! *Your* way, it is either (and LinuxAPI) or (and
WinAPI). The only way to do away with the (and ___) is to do it on
bare metal or in a simulator. A line must be drawn in the sand
somewhere.

An epiphany has recently come to me. I guess, due to the many
questions we witness over the years, I convinced myself that *some*
type of additional material (examples, tutorial, or wiki, etc.) is
indeed needed. Now I am wondering if this is a wrong conclusion.
Perhaps what those seekers really need is that which they already have
access to -- those books and online material that already exist; the
classrooms (complete with teacher and fellow students) that are
available to them.

Nathan.
nbaker2328
2008-03-17 08:41:18 UTC
Permalink
Post by DaveR
Hi
I'm just starting out trying to learn assembler, using HLA and the
"Art of Assembler". I am having problems executing very simple demo
programs.
A hello world program works, however as soon as I introduce a
variable, I get a segfault. I have given a working and broken example
below.
Apologies if I have done something stupid(!) , but any help would be
appreciated. Please let me know if you need anymore information to
help...
Kind Regards
David
Linux beechwood.home 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST
2008 i686 i686 i386 GNU/Linux
====WORKING=====
program helloWorld;
#include( "stdlib.hhf" );
begin helloWorld;
stdout.put( "Hello, World of Assembly Language", nl );
end helloWorld;
HLA (High Level Assembler)
Use '-license' to see licensing information.
Version Version 1.99 build 12923 (prototype)
ELF output
OBJ output using internal FASM back-end
-test active
HLA Lib Path: /home/david/local/hla/hlalib/hlalib.a
HLA include path: /home/david/local/hla/include
1: HelloWorld.hla
Compiling 'HelloWorld.hla' to 'HelloWorld.o'
[hlaparse -level=high -v -sf -celf -test "HelloWorld.hla"]
----------------------
HLA (High Level Assembler) Parser
use '-license' to view license information
Version Version 1.99 build 12923 (prototype)
-t active
File: HelloWorld.hla
Output Path: ""
Language Level: high
Compiling "HelloWorld.hla" to "HelloWorld.o"
Compilation complete, 14837 lines, 0.214 seconds, 69332 lines/
second
Using flat assembler version C1.66
3 passes, 1499 bytes.
----------------------
Linking via [ld -o "HelloWorld" "HelloWorld.o" "/home/david/local/
hla/hlalib/hlalib.a"]
Hello, World of Assembly Language
====BROKEN=====
HelloWorldWithVar.hla
program helloWorld;
#include( "stdlib.hhf" );
static
InitDemo: int32 := 5;
begin helloWorld;
stdout.put( "Hello, World of Assembly Language", nl );
stdout.put( "InitDemo's value is ", InitDemo, nl );
end helloWorld;
HelloWorldWithVar.hla
HLA (High Level Assembler)
Use '-license' to see licensing information.
Version Version 1.99 build 12923 (prototype)
ELF output
OBJ output using internal FASM back-end
-test active
HLA Lib Path: /home/david/local/hla/hlalib/hlalib.a
HLA include path: /home/david/local/hla/include
1: HelloWorldWithVar.hla
Compiling 'HelloWorldWithVar.hla' to 'HelloWorldWithVar.o'
[hlaparse -level=high -v -sf -celf -test "HelloWorldWithVar.hla"]
----------------------
HLA (High Level Assembler) Parser
use '-license' to view license information
Version Version 1.99 build 12923 (prototype)
-t active
File: HelloWorldWithVar.hla
Output Path: ""
Language Level: high
Compiling "HelloWorldWithVar.hla" to "HelloWorldWithVar.o"
Compilation complete, 15683 lines, 0.223 seconds, 70327 lines/
second
Using flat assembler version C1.66
3 passes, 1644 bytes.
----------------------
Linking via [ld -o "HelloWorldWithVar" "HelloWorldWithVar.o" "/
home/david/local/hla/hlalib/hlalib.a"]
Hello, World of Assembly Language
InitDemo's value is Segmentation fault
I am wondering if we have finally stumbled upon the cause of David's
troubles? Could it be that HLA is marking the '.text' sections of ELF
object files as type NOBITS (what a '.bss' section is usually typed
as) instead of the typical setting of PROGBITS?

I suspect that some versions of LD give a warning [ ld: section
`.text' type changed to PROGBITS ], while other versions make the
change silently, and still another version (which David was the
unlucky victum of) simply leaves the setting "as is" and thus
producing a binary with those items nulled-out.

http://www.masm32.com/board/index.php?topic=8873.0

Nathan.
Frank Kotler
2008-03-17 19:27:52 UTC
Permalink
nbaker2328 wrote:

...
Post by nbaker2328
Post by DaveR
InitDemo's value is Segmentation fault
I am wondering if we have finally stumbled upon the cause of David's
troubles? Could it be that HLA is marking the '.text' sections of ELF
object files as type NOBITS (what a '.bss' section is usually typed
as) instead of the typical setting of PROGBITS?
How come I didn't notice that??? Yeah, HLA *is* flagging some .text
sections (but not all) as NOBITS! I'm quite sure that this is "wrong,
period".
Post by nbaker2328
I suspect that some versions of LD give a warning [ ld: section
`.text' type changed to PROGBITS ], while other versions make the
change silently, and still another version (which David was the
unlucky victum of) simply leaves the setting "as is" and thus
producing a binary with those items nulled-out.
That seems probable. I can confirm that some versions of ld (2.15.90.0.3
here) do silently change a section *named* .text from writeable to
readonly. I'll bet it changes NOBITS to PROGBITS too. A NOBITS .text
section makes no sense at all to me... it's almost a "bug" in ld *not*
to change it... but that *is* what we said...
Post by nbaker2328
http://www.masm32.com/board/index.php?topic=8873.0
I'm embarrassed that the "evil board" spotted this and I didn't (having
a version of ld that complains is a help...). Well... given the "scent",
this shouldn't be too hard to track down...

This doesn't solve the issue of the legendary, perhaps mythical, "build
12923", but I think you've hit it. Nice work, Nathan!

Best,
Frank
rhyde@cs.ucr.edu
2008-03-27 16:31:35 UTC
Permalink
Post by DaveR
Hi
I'm just starting out trying to learn assembler, using HLA and the
"Art of Assembler".  I am having problems executing very simple demo
programs.
I've not followed this through to the end to see if the answer has
been posted here, but the problem seems to be in the code that FASM
generates under Linux. The quick work-around, until I update FASM to
work properly, is to use Gas as the back-end assembler under Linux.
Try compiling your programs with the "-xg" command-line option and see
if that helps.
hLater,
Randy Hyde

Loading...