flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > 07 dup 80*60*2 - value out of range? bug?

Author
Thread Post new topic Reply to topic
a16b03



Joined: 24 Jan 2006
Posts: 43
Location: Riga, Latvia
a16b03 07 Feb 2006, 12:15
I need to make data buffer that is 80*60*2 bytes long, but insted a get an error.

What is the max size, tha i can define?
Is it a bug?

80*60*2=9600B = 9.6 KB only
Post 07 Feb 2006, 12:15
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 07 Feb 2006, 13:07
You mess the syntax up. You should use
Code:
80*60*2 dup (07)    
Post 07 Feb 2006, 13:07
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 07 Feb 2006, 13:20
i never comprehended this stupid MASMy syntax... FASM's times is much clearer (but much slower if not internally optizimed...)
Post 07 Feb 2006, 13:20
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 07 Feb 2006, 13:31
It is not so stupid for me:

<how many times> DUPlicate <what>
Post 07 Feb 2006, 13:31
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 07 Feb 2006, 13:43
nice, but in real use:

<type of what> <how many times> DUPlicate <value of what>
db 5 dup 6

seems less logical. Not talking about repeating structures or whatever...

If I have structure POINT, which consists of two words, and i want to declare 5 zeroed POINTs, then due to last example it is

POINT 5 dup (0,0)

... ???
Post 07 Feb 2006, 13:43
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
Tomasz Grysztar 07 Feb 2006, 13:47
I rather see it as:
DB <how many> DUPlicates of <what>
Post 07 Feb 2006, 13:47
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias 07 Feb 2006, 17:12
In my opinion, this syntax is obsolete, developed originally in the 1970's when SPACE SAVINGS was PARAMOUNT. So, to save space, one was obliged to DB, DEFINE BYTE, or, specify the dimension, in bits, of a particular component of a data structure.
Of course, if one is engaged in MODERN thinking, MEMORY is a LOT CHEAPER than programming time, therefore, ONE deliberately SQUANDERS memory, (wastes it), BY ASSIGNING ALL VARIABLES to the same (32 bit) space, regardless of whether or not one actually uses only 8 bits, or, for that matter, only 1 bit.
Therefore, a MODERN Assembler, ought to possess a default setting which ASSUMES every data element to be the same 32 bit size. Of course, many will object to this--particularly those who deal with 64 bit operands, or floating point variables (80 bits), or those who use the newer 128 bit registers.
I don't insist that a USEFUL assembler MUST process all data as exclusively 32 bits, excluding all other possibilities, I simply ask that a modern assembler ASSUME a default setting of 32 bits, so that ONLY use of any other dimension requires an explicit designation by the programmer. Smile
Post 07 Feb 2006, 17:12
View user's profile Send private message Reply with quote
a16b03



Joined: 24 Jan 2006
Posts: 43
Location: Riga, Latvia
a16b03 07 Feb 2006, 21:31
This was stupid mistake.


thanks
Post 07 Feb 2006, 21:31
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost 11 Feb 2006, 05:31
tom tobias wrote:
In my opinion, this syntax is obsolete, developed originally in the 1970's when SPACE SAVINGS was PARAMOUNT. So, to save space, one was obliged to DB, DEFINE BYTE, or, specify the dimension, in bits, of a particular component of a data structure.
Of course, if one is engaged in MODERN thinking, MEMORY is a LOT CHEAPER than programming time, therefore, ONE deliberately SQUANDERS memory, (wastes it), BY ASSIGNING ALL VARIABLES to the same (32 bit) space, regardless of whether or not one actually uses only 8 bits, or, for that matter, only 1 bit.
Therefore, a MODERN Assembler, ought to possess a default setting which ASSUMES every data element to be the same 32 bit size. Of course, many will object to this--particularly those who deal with 64 bit operands, or floating point variables (80 bits), or those who use the newer 128 bit registers.
I don't insist that a USEFUL assembler MUST process all data as exclusively 32 bits, excluding all other possibilities, I simply ask that a modern assembler ASSUME a default setting of 32 bits, so that ONLY use of any other dimension requires an explicit designation by the programmer. Smile


sorry but i think that is a terrible idea being an assembler programming i often make use of 8,16,32,64bit because i try to be as optimized as possible

_________________
redghost.ca
Post 11 Feb 2006, 05:31
View user's profile Send private message AIM Address MSN Messenger Reply with quote
FrozenKnight



Joined: 24 Jun 2005
Posts: 128
FrozenKnight 11 Feb 2006, 11:27
If you want to start assumeing stuff go learn a programming language like C or C++. ASM is a language where you have full controll over what is going on.
Post 11 Feb 2006, 11:27
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.