forward referencing in masm32 and masm6.x

[bobl]

The next discrepancy in two images I'm looking at is at address 0x36 where the image that works has the byte 40h & the one that doesn't has byte 00h.
In both images this byte is followed by 3 zero bytes which corresponds with the listing below of the image that doesn't work
i.e. the directive ".int gdt0"

The listing for the file that doesn't work is

Code Select Expand


  69 0034 1700      gdt: .word 0x17
  70 0036 00000000 .int gdt0         #packed dword integer data (.byte=byte integer data/ .short=word integer data / .int=dword integer data)
  71 003a 660F1F44 .balign 8
  71      0000
  72 0040 00000000 gdt0: .word 0, 0, 0, 0
  72      00000000
  73 0048 FFFF0000 .word 0x0FFFF, 0, 0x9A00, 0x0CF# code
  73      009ACF00
  74 0050 FFFF0000 .word 0x0FFFF, 0, 0x9200, 0x0CF# data
  74      0092CF00


This area of bytes is accessed by "lgdt gdt" according to a bochs read watchpoint.
lgdt seems to read a 6byte (base address and limit) which I think corresponds to
.word 0x17 and .int gdt0 (the latter looks like it should be 40h (address of gdt0) and not 00h as in the listing).

The image without source seems to get this right whereas the image produced from this listing
gives 0 for the base address suggesting that gas doesn't do forward referencing.

I know MASM32 doesn't do forward referencing cos this popped up in a previous question but wonder if  masm6.x does
cos this was the original assembler used by Charles Moore and would explain this sort of discrepancy
i.e. caused by people copying his code into a non-forward referencing assembler..

EDIT:

Code Select Expand


Sample Code
-----------

; Assemble options needed in MASM 6.x: /c /Fl

_text   SEGMENT para public 'CODE'
        ASSUME cs:_text
start:
        jmp SHORT forward
forward:


I guess this answers my question but raises another i.e. why don't MASM32 and gas do forward referencing??
I suppose it shouldn't be that difficult to structure the code so that the referred to labels are before the references but this seems to imply more jumps doesn't it??

[BogdanOntanu]

The next discrepancy in two images I'm looking at is at address 0x36 where the image that works has the byte 40h & the one that doesn't has byte 00h.

If you intend to get helpful answers then I do recommend that you do explain what you are doing and how you reached to the current task/assumptions and problems in each new thread you start... or you can keep all related posts in the same thread and do the explanations only once at the start of thread.

This way people reading your thread can understand the problem and give meaningfully answers.

For example you should explain that you are trying to compile your own version of a FORTH implementation. also explain what implementation or source code you use and in what assembler you use to compile this source code.

It looks to me that you have some sources in GAS that do not compile correctly?  Or is it that you are trying to convert those sources to MASM syntax?

Also is this code 16bits or 32bits? It looks like 16 bits boot initialization code to me...

Without proper history and explanations the fact that "at byte 0x36" you have a problem has no meaning whatsoever to me... but I do understand that it might have some meaning to you. You also need to understand that you have to explain this in writing when you ask a question because it is possible that your whole path of thinking is wrong and the question alone has no real purpose.

In both images this byte is followed by 3 zero bytes which corresponds with the listing below of the image that doesn't work
i.e. the directive ".int gdt0"

This kind of directive does not exist in MASM.

The listing for the file that doesn't work is

Code Select Expand


  69 0034 1700      gdt: .word 0x17
  70 0036 00000000 .int gdt0         #packed dword integer data (.byte=byte integer data/ .short=word integer data / .int=dword integer data)
  71 003a 660F1F44 .balign 8
  71      0000
  72 0040 00000000 gdt0: .word 0, 0, 0, 0
  72      00000000
  73 0048 FFFF0000 .word 0x0FFFF, 0, 0x9A00, 0x0CF# code
  73      009ACF00
  74 0050 FFFF0000 .word 0x0FFFF, 0, 0x9200, 0x0CF# data
  74      0092CF00


Again this code looks alien. I suppose it is GAS? can you confirm this? Or you are using another assembler?

This area of bytes is accessed by "lgdt gdt" according to a bochs read watchpoint.

So you are using Bochs emulator to debug this boot code? Is this right?

lgdt seems to read a 6byte (base address and limit)

Yes it does, as it is clearly written in Intel CPU manuals.

which I think corresponds to
.word 0x17 and .int gdt0 (the latter looks like it should be 40h (address of gdt0) and not 00h as in the listing).

Yes it should be 40h .. IF the GDT base address is 40h.

The image without source seems to get this right whereas the image produced from this listing
gives 0 for the base address suggesting that gas doesn't do forward referencing.

How can you produce an "image" from an "listing" ? Try to be clear.

I doubt that ANY assembler can work without forward referencing for labels. It is kind of impossible to place labels before use in most non trivial program cases.

I know MASM32 doesn't do forward referencing cos this popped up in a previous question

How do you "know" this? It is obvious that MASM (and any assembler for that matter) has to do forward referencing for labels. Maybe you misunderstood an answer OR you obtained the wrong answer because your history/situation/question was not exact and clear. For example most assemblers can not perform forward referencing for MACRO's (and for good reasons) and some need PROTOTYPES for using INVOKE... and like C needs function signatures for each forward referenced function.

But I seriously doubt that any assembler (...not even GAS) can not do forward referencing for labels.

but wonder if  masm6.x does
cos this was the original assembler used by Charles Moore and would explain this sort of discrepancy
i.e. caused by people copying his code into a non-forward referencing assembler..

Again you jump to conclusions without having the proper experience and understandings. MASM32 is a package containing a lot of includes, a lot of macros and usefully libraries of code. It does use the MASM 6.x assembler internally or you can use another newer MASM version if you want and if you know how...

Hence it is conceptually impossible that MASM32 "does not do" forward reference and MASM 6.x "does" forward reference.

I guess this answers my question but raises another i.e. why don't MASM32 and gas do forward referencing??

I guess that you are completely out of your league here trying guess things you did not study or did not understand enough.

I suppose it shouldn't be that difficult to structure the code so that the referred to labels are before the references but this seems to imply more jumps doesn't it??

It is impossible to "structure the code" like this for most non trivial program hence you guess wrong again.

[bobl]

Bogdan
Thankyou for confirming that 40h should be in there

I could've given the background by referencing...
http://www.masm32.com/board/index.php?topic=12782.0
but didn't 'cos that thread is just one below this one, in the forum, and is also current.

I changed threads cos that thread seemed a bit long and was about something slightly different.

Re your comments that I am "inexperienced" and "out of my league"...
I'm "guilty as charged" but isn't that the purpose of "The Campus"?
i.e. Why would I ask a question on such a beginners forum if I was experienced
and sufficiently not out of my league to know the answer?
Given this your comments re my limitations seem a little gratuitous.
I mention this only because your tone could put off more sensitive souls.
That would be a real shame because it's clear you have a lot to offer.

Re the purpose of my thread and statement that "MASM32 doesn't do forward referencing"...
As an inexperienced out of my league beginner, I assembled (in gas)...

Code Select Expand


.int 0x40

and got what I expected.
I then assembled...

Code Select Expand


addr1    .int blob
addr2    nop
addr3    blob:

and did not understand the lack of a reference to addr3 in the opcode for the line ".int blob", hence my thread.

I then remembered the statement in
http://www.masm32.com/board/index.php?topic=12468.0
ie

Code Select Expand


PS: masm doesn't support forward referencing

but missed the further qualification

Code Select Expand


it will forward reference a label - but i did miss the offset - lol

If gas followed my misintepretation of how I thought MASM32 operated then this might explain why I wasn't seeing addr3 in ".int blob".
Given the thread's date, my inexperience and relative lack of straightforwardness of my task I think my misinterpretation is understandable?

============================================================================================================
The above is all my thread was seeking reassurance about really and I'm sorry if it confused you!
============================================================================================================

Although Forward referencing may be necessary in some situations I'm not sure it's as essential as you suggest.
ie
A while back I wrote a 24k line scientific simulation in c++.
To start with I didn't use headers and overcame forward referencing by careful placement of the variables and member functions.
Before switching to best practice I required only 3 forward references.
24-ish k lines of code represents medium complexity in DOD circles ie not trivial.

Things may be different for asm. Having said that Charles Moore's colorforth (this code) isn't trivial either, despite it's small size.
I'm quite prepared to believe that gas' seeming inability to reference forward labels is down to my inability to operate gas properly.

However, if the problem is not down to me, and is with gas, then the author of the working image appears to have eliminated forward referencing by hard coding the numerical values required.
Such numbers could be acquired from the sources, that are similar, in the same manner that I worked out what 40h was.
i.e. this would go some way to explaining why theres no 1 to 1 source for the working image, only something close from which the hard numbers could be taken.
Evidence supporting this view is that the working image (which does not quite correspond to the sources) works.

Whilst the disparity between sources and working image caused me a great deal of confusion initially there's no getting away from the fact that without this version of colorforth ie that runs under bochs I'd be stuffed. The author's efforts are therefore very much appreciated.

Your clarification of my misinterpretation re

Code Select Expand


    "Why gas won't put addr3 in the line .int blob?"

helps a lot because it re-raises this question to which I once again have no answer.
I do consider that to be progress so Thank you for your time

[dedndave]

don't mind bogdan - lol
he enjoys locking threads and moving them from one sub-forum to another
also - criticizing everyone
i rarely see him post any code
once in a while, he has a little bit of good info
you just have to sift through 50 lines of b.s. to find it   :bg

[MichaelW]

I cannot find any problems with GAS and forward references to labels. The attachment contains my test app.

[dedndave]

i have seen problems referencing EQUates before they are declared - but not address'ed labels

[BogdanOntanu]

don't mind bogdan - lol

Yes, you are free to ignore me ... unless... unless I act as a moderator. Do not ignore me when I ask about breaking the forum rules because in that case your thread might go to recycle bin very fast.

But you are safe here... yet :D

he enjoys locking threads and moving them from one sub-forum to another

Nope I do not enjoy it. It is just "work".

also - criticizing everyone

I will criticize somebody ONLY IF I do feel generous that day and only IF "somebody" has made a mistake and only IF I do detect / consider that my "criticism" could eventually help "somebody" evolve. IF any of the above if's is not true then I usually just smile and ignore.

For example you will rarely (if ever) see me criticize people that do know what they are talking about like Vortex, Japeth, Hutch, Donkey, Ultrano, Drizz, etc etc . I might criticize them in other non ASM areas like "evolution" :P

i rarely see him post any code

Yes this is true. And it is because I consider that everyone should write his own code. This teaches you much more than a "copy and paste" from somebody else's example. I prefer to offer concepts and guidance rather than example code. I consider my method to be better at teaching ASM but I do not interfere with people that consider otherwise.

However I have written in ASM: Hostile Encounter RTS game, Solar OS operating system and Sol_Asm assembler. Each one is a huge ASM only project that was written from scratch by me (sometimes with the help of some friends). Those projects are available for download and testing here: www.oby.ro

once in a while, he has a little bit of good info
you just have to sift through 50 lines of b.s. to find it   :bg

Thanks for your kind words ;)
The whole idea is to teach you how to search, detect and use "good info" hidden in "b.s." ;)

[dedndave]

there ya go  ^{^}_^
exactly what i am talking about - lol
i think he is his own worst enemy   :P

[NervGaz]

I get the feeling that Bogdan's been paying attention to the teachings of Fravia+.
If you're not familiar with F+ please ignore this as it could be seen as illegal on this
board considering his early work.

Mods. I was reffering to F+'s searchlores...

[BogdanOntanu]

Bogdan
Thankyou for confirming that 40h should be in there

You are welcome ;)

I could've given the background by referencing...
http://www.masm32.com/board/index.php?topic=12782.0
but didn't 'cos that thread is just one below this one, in the forum, and is also current.

IMHO you should have had...

Re your comments that I am "inexperienced" and "out of my league"...
I'm "guilty as charged" but isn't that the purpose of "The Campus"?

The purpose was to point you to the fact that probably your are making the wrong assumptions. Something like the beginner programmer that believes that he/she have found an "error in the C/C++ compiler" when in fact they do not know the language well enough.

And also it was intended as a pointer that maybe you started a much to complicated project for your current level of understanding of ASM. Maybe you should first try to write some simple test programs? Then you would notice that in ASM (unlike C/C++ or other HLL) forward referencing of labels is "of the essence" and required.

I mention this only because your tone could put off more sensitive souls.
That would be a real shame because it's clear you have a lot to offer.

It is my teaching style to be harsh at first. IMHO it works but if it does offend you or it does not work in your case then please excuse and know that there are a lot of other knowledgeable people here in those forums that are much more gentle.

Re the purpose of my thread and statement that "MASM32 doesn't do forward referencing"...
As an inexperienced out of my league beginner, I assembled (in gas)...

Maybe you should have stated that GAS does not do forward referencing... if you tested in GAS.
Anyway ... as I have said before I seriously doubt this even for GAS.

Although Forward referencing may be necessary in some situations I'm not sure it's as essential as you suggest.

It is of the essence for ASM.

ie
A while back I wrote a 24k line scientific simulation in c++.
To start with I didn't use headers and overcame forward referencing by careful placement of the variables and member functions.
Before switching to best practice I required only 3 forward references.
24-ish k lines of code represents medium complexity in DOD circles ie not trivial.

I do that all the time at work. But you should learn that C/C++ and other HLL languages can avoid the forward referencing for labels because they hide jumps inside structured programming loops like :IF/THEN/ELSE, WHILE, FOR, REPEAT, SWITCH/CASE and other such HLL constructs. Internally this is still done by jumps to labels that are forward referenced but the programmer is not aware of this.

However, in ASM programming the use of such HLL constructs like .IF/.THEN.ELSE or WHILE/REPEAT is optional and for most critical code the JUMPS are toward forward referenced labels.

Basically the assembler compiler has to do this no matter what but the HLL compiler can and usually does hide this from the programmer.

Having said that Charles Moore's colorforth (this code) isn't trivial either, despite it's small size.
I'm quite prepared to believe that gas' seeming inability to reference forward labels is down to my inability to operate gas properly.

Most likely. That is why I suggested you should first gain some ASM programming experience before starting such a task of porting one application from one assembler syntax to another. There are subtle differences that can ruin you a lot of time even if you do know ASM well "enough".

However, if the problem is not down to me, and is with gas, then the author of the working image appears to have eliminated forward referencing by hard coding the numerical values required.

Very unlikely. This kind of thinking and assumptions are wrong.

Evidence supporting this view is that the working image (which does not quite correspond to the sources) works.

Maybe you got the wrong sources... or you are not able to comprehend them yet... but IMHO you are deeply wrong if you believe somebody hard coded the forward references for this program.

Hardcoding forward references for a large application would be an insane task to perform and a futile one also... this is the "task of the assembler" and not for a human to perform... maybe you should change your "frame of mind" and search for another more plausible explanation?

[dedndave]

If you're not familiar with F+ please ignore this as it could be seen as illegal on this
board considering his early work.

nah - lol - i think Hutch was a Fravia fan/acquaintant/friend
http://www.masm32.com/board/index.php?topic=11408.msg84814#msg84814

[bobl]

Thank you very much everyone for your support and assistance.
Yes even you Bogdan!
This is a bit of a challenge given my skills set but I'm not unused to leading with my face and so will continue with my struggle if it's ok with you?

Re your suggestion of trying simpler stuff before attempting my project, its prolly worth pointing out that I did write such programs before starting this thread.
ie

Code Select Expand


;In nasm dd equates to .int in gas
;In nasm I produced a flat binary with "nasm test.asm -o test.bin"
;on
;test.asm
   dd 40h
;which gives...00000000 40 00 00 00
;ie as expected

;Similarly
;test.asm
   ;dd blob
   ;nop
   ;blob:
;gives...00000000 05 00 00 00 90
;ie as expected

#In gas I produced a flat binary with
#as test.s
#objcopy -O binary a.out a.com
on
#test.s
.int 0x40
#which gives...00000000 40 00 00 00
#ie as expected

#Unfortunately
#test.s
.int blob
nop
blob:
#gives...00000000 00 00 00 00 90.
#which is not what I expect and is my problem


I can't really see how I can write anything much simpler than this?

Michael thank you for your snippet. It's very much appreciated!
That's the sort of thing I was looking for and I can see that it works.
Unfortunately colorforth tends to lack the formatting in your code so we may not be comparing apples with apples but it's reassuring to know that gas forward references labels. I just have no idea why my last gas test doesn't work when the same trivial test passes with flying colors in nasm???

Bogdan
The colorforth disk image "weighs" in at about 32k "dripping wet" (including forth blocks) and tests with vbindiff reduce that code to 11.4k i.e. the address of the last difference between images.
The size of the code is further reduced by considering that there's a lot of space in between the various chunks so we could be looking at about 8k.
I'm surprised that you think this is a large application incapable of being hard coded with the values of forward references.
Charles Moore apparently hand assembled some of the instructions so manual manipulation doesn't seem to bother them.

dedndave
As always, an education and pleasure!

[bobl]

Whilst comparing the supplied colorforth source code to MichaelW's to see why his succeeds & colorforth and my sources fail, I came across this at the very start of the colorforth code...

# .MODEL TINY
# .486P
#only SEGMENT USE32
# ASSUME

This looks like masm 6.x to me. If correct this supports my previously dismissed belief that the code is masm 6.x copied, pasted & hacked to run under gas.
Knowing this is useful 'cos I can look out for repeated errors arising from inconsistencies between the two assemblers.
Knowing this it may be that the colorforth sources are missing some crucial gas instruction/directive that enables forward referencing. I don't know but it seems like a step further.

[japheth]

#Unfortunately
#test.s
.int blob
nop
blob:
#gives...00000000 00 00 00 00 90.
#which is not what I expect and is my problem

I tried to reproduce this problem.

the source ( TEST.S):

Code Select Expand


.int gdt
gdt:


the assembler ( AS.EXE v2.16.91 contained in MinGW ) is called this way:

as TEST.S

the output file is A.OUT. If I feed this file to MS DUMPBIN (v7.10.3077) with /DISASM option, it displays

Code Select Expand


Microsoft (R) COFF/PE Dumper Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file a.out

File Type: COFF OBJECT

  00000000: 04 00              add         al,0
  00000002: 00 00              add         byte ptr [eax],al
gdt:
  00000004: 90                 nop
  00000005: 90                 nop
  00000006: 90                 nop
  00000007: 90                 nop
  00000008: 90                 nop
  00000009: 90                 nop
  0000000A: 90                 nop
  0000000B: 90                 nop
  0000000C: 90                 nop
  0000000D: 90                 nop
  0000000E: 90                 nop
  0000000F: 90                 nop

  Summary

           0 .bss
           0 .data
          10 .text


As you can easily see, there's a 04 byte at address 0, which is exactly what I'd expect. So IMO gas has absolutely no problems with forward references to labels.

[bobl]

I just copied your source and produced the following output that omits the 04 with
"as test.s; objcopy -O binary a.out a.com; hte a.com"
ie it gives...

Code Select Expand


"00000000 00 00 00 00"


My gnu assembler is for crunchbang linux on AMD64.
This seems reminiscent of when you showed that wlink linked gas better under windows than gas' own linker, under both linux & windows that MichaelW kindly tried.
I'm going to have to get to the bottom of this cos it's ridiculous.
Thx for your help


EDIT:
Cos of your success and my failure with same program I switched machines and am writing this on my PIII running ANTIX linux.
I've just tried the same program using the same command line and this time, like you, get...

Code Select Expand


00000000 04 00 00 00                                     |?               |

Thx for giving me the nudge to try this 'cos I couldn't conceive that this sort of error could have existed in such a fundamental component of Linux and not cause a major problem.
What's very surprising is that I actually compiled some apps from source and they worked!
Anyway that's that one sorted so thanks once again to everyone who posted.
So much for beginners luck!