flat assembler
Message board for the users of flat assembler.

Index > Main > complex strucs

Author
Thread Post new topic Reply to topic
Miguel



Joined: 16 Jun 2003
Posts: 21
Location: Spain
Miguel
Hello at alls...after very long time without net conexion
...six months..from new i´m in the net ..i´m happy..
Who help me to convert thats strucs to fasm sintax?

Thanks to alls (Conrade,Scientica,JFound,Tomasz of course...etc)
(No me olvido de ti Pelaillo ni del resto de la gente
de la que estoy aprendiendo.....gracias)


IRP STRUC
irpType WORD 6
irpSize WORD ?
MdlAddress PVOID ?
Flags DWORD ?
UNION AssociatedIrp
MasterIrp PVOID ?
IrpCount DWORD ?
SystemBuffer PVOID ?
ENDS
ThreadListEntry LIST_ENTRY {}
IoStatus IO_STATUS_BLOCK {}
RequestorMode BYTE ?
PendingReturned BYTE ?
StackCount BYTE ?
CurrentLocation BYTE ?
Cancel BOOLEAN ?
CancelIrql BYTE ?
ApcEnvironment BYTE ?
AllocationFlags BYTE ?
UserIosb PIO_STATUS_BLOCK ?
UserEvent PKEVENT ?
UNION Overlay
AsynchronousParameters ASYNCHRONOUS_PARAMETERS {}
AllocationSize LARGE_INTEGER {}
ENDS
CancelRoutine DWORD ?
UserBuffer DWORD ?
UNION Tail
STRUCT Overlay
UNION
DeviceQueueEntry KDEVICE_QUEUE_ENTRY {}
STRUCT
DriverContext PVOID 4 dup(?)
ENDS
ENDS
Thread PVOID ?
AuxiliaryBuffer PCHAR ?
STRUCT
ListEntry LIST_ENTRY {}
UNION
CurrentStackLocation PVOID ?
PacketType DWORD ?
ENDS
ENDS
OriginalFileObject PVOID ?
ENDS
Apc KAPC {}
CompletionKey PVOID ?
ENDS
IRP ENDS
PIRP TYPEDEF PTR _IRP





KGDTENTRY STRUCT
LimitLow WORD ?
BaseLow WORD ?
union dwHighWord
struct Bytes
BaseMid BYTE ?
Flags1 BYTE ?
Flags2 BYTE ?
BaseHi BYTE ?
ends


Bits RECORD \
u11BaseHi:8,
u11Granularity:1,
u11Default_Big:1,
u11Reserved_0:1,
u11Sys:1,
u11LimitHi:4,
u11Pres:1,
u11Dpl:2,
u11Type:5,
u11BaseMid:8
ends
KGDTENTRY ENDS
PKGDTENTRY typedef PTR KGDTENTRY

..I think that bitfields will be:
u11BaseHi rb 8
u11Granularity rb 1
..........
But,in memory,they will be in yours correct order?

_________________
Hola,Hello...my english is not good..but..
we understand us.....
Post 21 Mar 2004, 16:43
View user's profile Send private message Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
Hello Miguel, welcome back on-line.
About your questions, there are some missing information. I will try to give an answer but I'm not sure if this is what you are looking for.
There are some details that depends on the application you will give to the code. i.e. how do you use the structures.
Union lets you to access same memory location with different names and it could be achieved easily with virtual directive.

See more details here:
http://board.flatassembler.net/topic.php?t=149&highlight=union
and
http://board.flatassembler.net/topic.php?t=273

Bitfields are treated better in other ways in assembly using bitwise logic operators. IMO, preparing a translation of C approach is not a good idea, this is assembly territory.

Espero sea de ayuda,
pelaillo
Post 21 Mar 2004, 22:32
View user's profile Send private message Yahoo Messenger Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Smile
Salut Miguel, I share your fond opinion of Pelaillo, however, as he knows, I disagree with him on this one small point. I disagree with his suggestion that bitwise operators offer an advantage (or represent some sort of obligation or requirement in attempting to perform assembly language programming.) I look at your VERY COMPLICATED data structure, Miguel, AND I CONFESS, I don't understand anything. So, please discount my remarks, because I am wholly ignorant of what you are really trying to accomplish. I would propose, contrary to cher Pelaillo, that YOU CONVERT YOUR data structure to one that is VERY SIMPLE, by expanding all DATA TYPES to represent 32 bit words, and employ ONLY direct addressing mode to access the individual elements (thereby essentially WASTING lots of memory, and taking up extra clock cycles to execute.) WHY should one use 32 bit values instead of a single bit? The answer is readability. Memory is cheap. Programming time and effort are precious. Adding the additional (UNNECESSARY) complication of BITWISE OPERATORS, as Pelaillo has suggested, only makes your entire program all the more obscure. (I deliberately refrain from introducing the prolonged execution times needed for the bit-wise operations, for reasons well known to Pelaillo). Pelaillo is correct, of course, and I am wrong, about the consensus attitude among programmers, not only on this forum, but everywhere, all of whom would attest to the correctness of his suggestion and the error of my own idea. Though 99% of the folks disagree with me, I think Miguel, that your excellent submission accurately supports my contention that simpler design and greater readabilty are superior to shorter code space with its accompanying improved memory utilization. I would welcome a criticism of this viewpoint from those who can read Miguel's data structure and explain it. I can not. Smile Regards, tom tobias
Post 22 Mar 2004, 18:23
View user's profile Send private message Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
Dear tom tobias,
I think you have missed my point totally and I'm sorry that you get as a personal fact the think that other coders don't follow all of your ideas. Sad

For me as a coder, everithing does matter: Size, Speed and Readability. I am still a beginner in assembly but I have posted some code that I bet you haven't read. Readability is my first priority and I challenge you to find a single line that lacks on readability Wink (I have old source code that I don't post because is not readable)

If you read my previous post without passion, you will find that I was suggesting exactly the same thing: simplify data structures following Miguel needs.

About bitfields, my mind is:
I am against mixed information packed in dwords (exceptions exists, as usual)
But I don't see a purpose in WASTING a dword for any bit of information if you can do something like this:

Code:
read_flags:
   test MIGUEL_FLAGS,FLAG1_ON
   je   flag1_is_on
   jmp  go_ahead

flag1_is_on:
   test MIGUEL_FLAGS,FLAG2_ON
   jne  flag2_is_off
    


I see it very readable, maintainable, simple, clear and safe. Very easy to set, clear and read. Don't you?

I have learned that own coding style cannot be imposed. People follow examples. So show your code and relax Smile
Time will tell.
Post 22 Mar 2004, 19:48
View user's profile Send private message Yahoo Messenger Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
HI Pelaillo,
Sorry if my previous post was misinterpreted, I did not mean to offend you, or suggest that you were doing anything wrong. As you wrote, I may indeed have missed the point entirely. My apologies if so.
Concerning your program, YES, it is very readable, thank you. Well done. UMM, I have a couple of suggestions, and perhaps you will find them banal, or stupid. No problem, just ignore them, then.
The question we were discussing was BIT WISE operations, and I made the point, perhaps incorrectly, that there is no need for them. Your reply confirmed your approval of bit wise instructions, so it would appear that we have a USEFUL metric for analyzing the situation. Excellent. Thank you for this perfect illustration, to explain our different approaches. As you pointed out, correctly, one's coding style cannot be imposed. You are right, of course. I am offering these comments not because I think I am right and you are wrong, but rather because I perceive some possible improvement in your thinking, GOOD AS IT ALREADY IS. Let's begin:
You have described a variable, called MIGUEL_FLAGS, which represents a single bit. I would perfer to use the variable called: SEMAPHORE, which represents 32 bits, squandering 31 bits. Why do I call it semaphore, rather than Miguel_flags? Well, because there is nothing special about the flags that Miguel is using, they could equally well be Tomasz' flags, or Comrade's flags, or anybody else's flags. Nothing special about Miguel. Why make it more difficult to figure out??? A semaphore is a flag. For that matter, one could call it FLAG. I agree with your logic. What you are trying to accomplish Pelaillo, is scrutiny of a variable, called whatever, to verify that if that variable is SET , i.e. = 1, i.e. NOT EQUAL ZERO, then, proceed to execute some other bit of code, BUT, if that variable, called whatever, HAS NOT BEEN SET, i.e. still equal zero, then, CONTINUE to execute the code which follows. Here's how I would write that (having defined ZERO as a constant with a value = 0, and assuming that the variable called semaphore now contains the 32 bit value equal to either zero or any other value, depending upon some action in the code above this point):

cmp semaphore,zero ; flag (i.e. semaphore) is set?
jne first_task ; yes, semaphore is not equal to zero, therefore, perform first task
jmp second_task ; no, the semaphore has been reset to a value of zero, so skip the first task
first_task:
...
second_task:

Why do we need to use "TEST", an instruction that computes the bitwise logical AND of the two operands? CMP, compare, is both adequate, and sufficient for control of program flow. THE GOAL IS SIMPLIFICATION. THERE IS no need to employ "TEST", for such a simple branch. The TEST instruction is one of those I hope to eliminate from the prospective set of REDUCED INSTRUCTIONS for the Intel cpu. Regards, Tom
Post 22 Mar 2004, 21:47
View user's profile Send private message Reply with quote
Miguel



Joined: 16 Jun 2003
Posts: 21
Location: Spain
Miguel
Confused Embarassed
From winbase.h :

typedef struct _DCB {
DWORD DCBlength;
DWORD BaudRate;
DWORD fBinary: 1;-----------------¡
DWORD fParity: 1; ¡.. here is the problem
DWORD fOutxCtsFlow:1; ¡
DWORD fOutxDsrFlow:1; ¡
DWORD fDtrControl:2; ¡
DWORD fDsrSensitivity:1; ¡
DWORD fTXContinueOnXoff: 1; ¡
DWORD fOutX: 1; ¡
DWORD fInX: 1; ¡
DWORD fErrorChar: 1; ¡
DWORD fNull: 1; ¡
DWORD fRtsControl:2; ¡
DWORD fAbortOnError:1; ¡
DWORD fDummy2:17;-----------------¡ ¡
WORD wReserved;
WORD XonLim;
WORD XoffLim;
BYTE ByteSize;
BYTE Parity;
BYTE StopBits;
char XonChar;
char XoffChar;
char ErrorChar;
char EofChar;
char EvtChar;
WORD wReserved1;
} DCB, *LPDCB;
How to convert to fasm´s syntax???

.....something in that way? :


struc DCB
{
.DCBlength DD ?
.BaudRate DD ?
.A_Label DD ?
virtual at A_Label

.fBinary ? ? ?
.fParity ? ? ?
.fOutxCtsFlow ? ? ?
.fOutxDsrFlow ? ? ?
.fDtrControl ? ? ?
.fDsrSensitivity ? ? ?
.fTXContinueOnXoff ? ? ?
.fOutX ? ? ?
.fInX ? ? ?
.fErrorChar ? ? ?
.fNull ? ? ?
.fRtsControl ? ? ?
.fAbortOnError ? ? ?
.fDummy2 ? ? ?

end virtual

.wReserved DW ?
.XonLim DW ?
.XoffLim DW ?
.ByteSize DB ?
.Parity DB ?
.StopBits DB ?
.XonChar DD ?
.XoffChar DD ?
.ErrorChar DD ?
.EofChar DD ?
.EvtChar DD ?
.wReserved1 DW ?
}
struct DCB

...thanks...

_________________
Hola,Hello...my english is not good..but..
we understand us.....
Post 23 Mar 2004, 00:48
View user's profile Send private message Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
Sorry tom tobias, I am not good to explain myself. It happens even in spanish, so imagine it in english.
I tend often to neglect details, so I will try again. I am going to use a "real" example from a non-trivial small program I wrote and post here: http://board.flatassembler.net/topic.php?t=1068
Interested portions are here:
Code:
; setting output flags here:
  .alink_output:
 or    [out_flag],OUT_FLAG_ALINK
     jmp   .next_args
  .golink_output:
   mov   [out_flag],OUT_FLAG_GOLINK
    jmp   .next_args
  .wide_char:
       or    [out_flag],OUT_FLAG_WIDE
      jmp   .next_args
; more code here...
; ... and here we check one of the bits
; contained in out_flag dword
 test  [out_flag],OUT_FLAG_WIDE
      je    .name_ascii
   mov   byte [edi],'W'
      jmp   .name_wide
  .name_ascii:
      mov   byte [edi],'A'
  .name_wide:
 inc   edi    
Post 23 Mar 2004, 03:43
View user's profile Send private message Yahoo Messenger Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
Hola Miguel,
Note that the following names refer to given number of bits from a same dword
Code:
         0000 0000 0000 0000|0000 0000 0000 0000

fBinary: 1-------------------------------------|
fParity: 1------------------------------------|
fOutxCtsFlow:1-------------------------------| 
fOutxDsrFlow:1------------------------------| 
fDtrControl:2----------------------------||
fDsrSensitivity:1-----------------------|
fTXContinueOnXoff: 1------------------|
fOutX: 1-----------------------------|
fInX: 1-----------------------------|
fErrorChar: 1 ---------------------|
fNull: 1 ---------- -------------|
fRtsControl:2 -----------------||
DWORD fAbortOnError:1 --------|
DWORD fDummy2:17 ;unused    


You need this kind of description when programming in C language.
In assembly you access single bits directly and in a simpler way. Read help for OR, AND, TEST.
Post 23 Mar 2004, 03:56
View user's profile Send private message Yahoo Messenger 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-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.