News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Declaring large blocks of data

Started by donkey, December 10, 2007, 11:38:06 PM

Previous topic - Next topic

donkey

Hi Jeremy,

I have been trying to declare a large block of data as a constant in an include file...

MJPGHDTSEG_STORAGE 0xFF, 0xC4, 0x01, 0xA2, 0x00, 0x00, 0x01, 0x05,\
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00,\
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x02,\
0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A,\
0x0B, 0x01, 0x00, 0x03, 0x01, 0x01, 0x01, 0x01,\
0x01, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00,\
0x00, 0x00, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05,\
0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x10, 0x00,\
0x02, 0x01, 0x03, 0x03, 0x02, 0x04, 0x03, 0x05,\
0x05, 0x04, 0x04, 0x00, 0x00, 0x01, 0x7D, 0x01,\
0x02, 0x03, 0x00, 0x04, 0x11, 0x05, 0x12, 0x21,\
0x31, 0x41, 0x06, 0x13, 0x51, 0x61, 0x07, 0x22,\
0x71, 0x14, 0x32, 0x81, 0x91, 0xA1, 0x08, 0x23,\
0x42, 0xB1, 0xC1, 0x15, 0x52, 0xD1, 0xF0, 0x24,\
0x33, 0x62, 0x72, 0x82, 0x09, 0x0A, 0x16, 0x17,\
0x18, 0x19, 0x1A, 0x25, 0x26, 0x27, 0x28, 0x29,\
0x2A, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3A,\
0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4A,\
0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 0x5A,\
0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6A,\
0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7A,\
0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8A,\
0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 0x99,\
0x9A, 0xA2, 0xA3, 0xA4, 0xA5, 0xA6, 0xA7, 0xA8,\
0xA9, 0xAA, 0xB2, 0xB3, 0xB4, 0xB5, 0xB6, 0xB7,\
0xB8, 0xB9, 0xBA, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6,\
0xC7, 0xC8, 0xC9, 0xCA, 0xD2, 0xD3, 0xD4, 0xD5,\
0xD6, 0xD7, 0xD8, 0xD9, 0xDA, 0xE1, 0xE2, 0xE3,\
0xE4, 0xE5, 0xE6, 0xE7, 0xE8, 0xE9, 0xEA, 0xF1,\
0xF2, 0xF3, 0xF4, 0xF5, 0xF6, 0xF7, 0xF8, 0xF9,\
0xFA, 0x11, 0x00, 0x02, 0x01, 0x02, 0x04, 0x04,\
0x03, 0x04, 0x07, 0x05, 0x04, 0x04, 0x00, 0x01,\
0x02, 0x77, 0x00, 0x01, 0x02, 0x03, 0x11, 0x04,\
0x05, 0x21, 0x31, 0x06, 0x12, 0x41, 0x51, 0x07,\
0x61, 0x71, 0x13, 0x22, 0x32, 0x81, 0x08, 0x14,\
0x42, 0x91, 0xA1, 0xB1, 0xC1, 0x09, 0x23, 0x33,\
0x52, 0xF0, 0x15, 0x62, 0x72, 0xD1, 0x0A, 0x16,\
0x24, 0x34, 0xE1, 0x25, 0xF1, 0x17, 0x18, 0x19,\
0x1A, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x35, 0x36,\
0x37, 0x38, 0x39, 0x3A, 0x43, 0x44, 0x45, 0x46,\
0x47, 0x48, 0x49, 0x4A, 0x53, 0x54, 0x55, 0x56,\
0x57, 0x58, 0x59, 0x5A, 0x63, 0x64, 0x65, 0x66,\
0x67, 0x68, 0x69, 0x6A, 0x73, 0x74, 0x75, 0x76,\
0x77, 0x78, 0x79, 0x7A, 0x82, 0x83, 0x84, 0x85,\
0x86, 0x87, 0x88, 0x89, 0x8A, 0x92, 0x93, 0x94,\
0x95, 0x96, 0x97, 0x98, 0x99, 0x9A, 0xA2, 0xA3,\
0xA4, 0xA5, 0xA6, 0xA7, 0xA8, 0xA9, 0xAA, 0xB2,\
0xB3, 0xB4, 0xB5, 0xB6, 0xB7, 0xB8, 0xB9, 0xBA,\
0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7, 0xC8, 0xC9,\
0xCA, 0xD2, 0xD3, 0xD4, 0xD5, 0xD6, 0xD7, 0xD8,\
0xD9, 0xDA, 0xE2, 0xE3, 0xE4, 0xE5, 0xE6, 0xE7,\
0xE8, 0xE9, 0xEA, 0xF2, 0xF3, 0xF4, 0xF5, 0xF6,\
0xF7, 0xF8, 0xF9, 0xFA


The values are BYTE size and if I try to use it in my code as follows...

something DB MJPGHDTSEG_STORAGE

I get the following error...

Data declaration too small assuming it should hold at least a 32-bit address:-DB MJPGHDTSEG_STORAGE

So, if I put a DB in the first line of the constant as follows

MJPGHDTSEG_STORAGE DB   0xFF, 0xC4, 0x01, 0xA2, 0x00, 0x00, 0x01, 0x05,\

And declare it like this

something MJPGHDTSEG_STORAGE

GoAsm accepts it but the data is wrong.

Any ideas on how I can do this or should I just declare it directly in my .DATA section ?

Donkey
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

Tight_Coder_Ex

Compilers have their underlying foundation in a command line structure, so as with earlier days of DOS where you could only enter a command line of 256 bytes this may be the case here. I think removing "\" and replacing each line with a preceding DB may solve the problem.

donkey

Quote from: Tight_Coder_Ex on December 11, 2007, 03:06:10 AM
Compilers have their underlying foundation in a command line structure, so as with earlier days of DOS where you could only enter a command line of 256 bytes this may be the case here. I think removing "\" and replacing each line with a preceding DB may solve the problem.

HI.

That was the first thing I tried and it did not work, I believe this is a compiler limitation and I am looking fo a work-around

Donkey
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

jorgon

Hi Donkey

Your code
MJPGHDTSEG_STORAGE=0xFF etc....
then
something DB MJPGHDTSEG_STORAGE
should assemble ok, so this is a bug.
I'll come back to you on this one asap.
I'll also look into the "data wrong" thing with the alternative.
Thanks for pointing out this error.
Author of the "Go" tools (GoAsm, GoLink, GoRC, GoBug)

ToutEnMasm

When constant are too big,we can cut them in small pieces.
Theone = ..
TheTwo = ...
  Thecst = Theone + TheTwo +...

Large data can be put in libraries with a public symbol

jorgon

Donkey

Could I just check with you that you did use the "=" sign between

MJPGHDTSEG_STORAGE and 0xFF?

I could see there was a character there in your code snippet, and assumed it was the equals sign but it may be a tab instead.
It's just that when I put the data block in an include file and omit the equals sign, then I get the same error message as you but when I use the equals sign the data assembles ok.

Whilst digging around with this I noticed that if you define the data block using MACRO..ENDM to avoid using the continuation characters, then GoAsm is not particularly happy with this.  That particular problem does seem to be a bug, and I wondered if this is what you originally tried to do and this misled you into assuming there was a general problem with defines/equates/macros declared in this way.

Author of the "Go" tools (GoAsm, GoLink, GoRC, GoBug)

donkey

Hi Jeremy,

I used #define, though the = sign gives me the same error. I have attached the header file and an example of how I tried to declare it.

Edgar

[attachment deleted by admin]
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

donkey

Hi Jeremy,

It seems that the problem only appears if the data block is not in the same file as the declaration. If I move the declaration to my .asm file it seems to assemble file, however when it is present in the .H file the error appears.

Edgar
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

jorgon

Edgar

Thanks for sending me the files you were using.

I found an orphaned
#ifdef GUID_DEFINED
on line 1934 of your include file with no matching #endif close by, as occcured in an earlier part of the include file, so that if GUID_DEFINED was not defined the rest of the file (including your bank of data) was being ignored.  This explains why the bank of data worked ok in the asm file and also worked for me.

This raises two questions about GoAsm error messages -

  • You got the error message
Data declaration too small assuming it should hold at least a 32-bit address:-
DB MJPGHDTSEG_STORAGE

This was because MJPGHDTSEG_STORAGE was not found as an define/equate/macro so GoAsm assumed it must be a label defined later in the asm file itself or which would be picked up at link-time from some other module.  As a label, however, the data size was too small since a label's address has to be 32bits and so does not fit into a byte.  In the circumstances it is difficult to think of a way in which this error message could be improved.
[li]You did not get an error message from the include file to tell you there was an orphaned "if".  This is by design.  GoAsm does not show an error but just ignores anything in an include file it does not understand.  This means users don't have to do too much stripping out of header files to enable them to be used by GoAsm.  However, maybe this "no error message" rule is too strict.  Clearly if you are cutting and pasting part of an include file, or deleting sections of it, you could easily leave an orphaned "if" or an unclosed comment without realising it. 
Would it be a good idea for GoAsm to show an error if it finds an orphaned "if" or unclosed comment in an include file?[/li]
[/list]

Author of the "Go" tools (GoAsm, GoLink, GoRC, GoBug)

donkey

Hi Jeremy,

Thanks for the help, the orphaned #IF was definitely the problem, all is working fine now. I think that an error message for this type of problem would be a good idea as long as it is simply a warning, and does not stop the compilation. It would help me to spot problems in the header files I am still wading through as well as to spot any problems in ones I have already translated. I had to drop the header project for a number of months but I'm back at it on weekends, I get one or two files a week done so it will still be a while.

Edgar
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

jorgon

QuoteWhilst digging around with this I noticed that if you define the data block using MACRO..ENDM to avoid using the continuation characters, then GoAsm is not particularly happy with this.  That particular problem does seem to be a bug ..
Actually on second thoughts I don't think this is a bug.  I misled myself here, since I never use macros (but respect those who do).

I worked this out as follows:-
Suppose you have:
MACRONAME MACRO 23,24,
                25,26
        ENDM

Then have:-
SOMETHING DB MACRONAME

You would expect to end up with:-
SOMETHING DB 23,24,
             25,26


and not with:-
SOMETHING DB 23,24,25,26

In other words, the macro ought to retain its line-endings.  The former is defective as a data declaration, so you would need the continuation characters after all in this example.
I hope I have got this right now.

Anyway I did add a warning message where an #if, #elif, #elseif, #ifdef or #ifndef is still open at the end of a non "a" extension include file (that is an include file such as "filename.inc" which is just looked at and not actually assembled as a file containing source code).  There is also a warning if there is a continuous "C" style comment (/* .....*/) open at the end of such a file.

I have also made the following amendments:-
1. In for example [esp+eax*4] the "4" could be defined using a word (32-bits only for the time being).
2. Error message upon eg. [esp+(eax*4)] since round brackets are not needed and upset the brackets parser!
3. GoAsm was missing labels in static code libraries made with some tools and which contained line number information.  This has now been fixed.  Probably it's unusual for line number information to be contained in a static code library which I suspect is why this bug has only just been reported to me.
4. In data declarations made using MACRO...ENDM (as above) if the data started on the next line, it was being missed.  This has now been fixed.

I attach the latest GoAsm with these changes.



[attachment deleted by admin]
Author of the "Go" tools (GoAsm, GoLink, GoRC, GoBug)