BBC BASIC for Windows
Programming >> Assembly Language Programming >> Passing Parameters with SYS
http://bb4w.conforums.com/index.cgi?board=assembler&action=display&num=1252729031
Passing Parameters with SYS
Post by Michael Hutton on Sep 12th, 2009, 04:17am

Hello,

In the WIki article on Passing data to assembler code. It states when passing parameters to SYS calls

Code:
.address
      mov ebp,esp
      mov eax,[ebp+4] ; now eax=par1%
      mov ebx,[ebp+8] ; now ebx=par2%
      mov ecx,[ebp+12] ; now ecx=par3%
      mov edx,[ebp+16] ; now edx=par4%
      ; do something useful
      ret 16 ; discard parameters


Am I missing something when I say:

Code:
.address
      mov eax,[esp+4] ; now eax=par1%
      mov ebx,[esp+8] ; now ebx=par2%
      mov ecx,[esp+12] ; now ecx=par3%
      mov edx,[esp+16] ; now edx=par4%
      ; do something useful
      ret 16 ; discard parameters


instead?

Obviously, if you want to save the state of the registers with a pushad then popad you would need to change the relative addresses of the [esp+x] or is there something more subtle I am missing here?

Michael

Re: Passing Parameters with SYS
Post by admin on Sep 12th, 2009, 07:15am

Quote:
Obviously, if you want to save the state of the registers with a pushad then popad you would need to change the relative addresses of the [esp+x] or is there something more subtle I am missing here?

I don't think there's anything more "subtle", but keeping track of your stack usage so you know what offset to apply with [esp+x] can be a major hassle.

There have been many occasions when a program I have written has failed 'inexplicably' as a result of simply adding an extra push/pop around a piece of assembler code. That is usually a totally safe thing to do, but if you access the stack relative to esp in that code it will fail.

If you look at the output of almost any C compiler you'll see that accesses to the stack (which are common, because that's where 'local' variables are stored) are done exactly as the first code snippet you listed: esp is first copied into ebp and the data are accessed relative to ebp. Indeed that's what the ebp register is for, as you can tell by the fact that its default segment is ss: (that is, [ebp] is actually shorthand for ss:[ebp]).

It's another one of these 'information hiding' things. You should, wherever possible, avoid writing 'fragile' code which is more likely to fail as the result of a later change. Accessing [esp+x] deeply inside some code can mean that a change apparently completely unrelated to (i.e. structurally far away from) that code can cause it to fail. This is very bad practice.

So, unless you vitally need to keep ebp free for other purposes, it's always better to use it in preference to esp to access stack contents (and, yes, I know I don't always strictly adhere to this advice myself!).

Richard.
Re: Passing Parameters with SYS
Post by Michael Hutton on Sep 14th, 2009, 2:30pm

Thanks Richard,

I suspected as much and the advice on creating safe code is appreciated.

On another note I have been looking for a good C or C++ IDE and compiler with which I can do exactly what you say. Write fast routines which I can put in a dll and then call from BB4W and/or look at the ASM output of the compiler.

I know this might sound like an idiot question but do you have any recommendations as to what 'package' would be a good place to start? There are a lot of options out there which I have looked at. Some of them seem very 'form' orientated. I have downloaded the demo 'embarcadero'

www.embarcadero.com/products/rad-studio

and am still wading through the documentation and examples. It looks as if creating dll's etc is possible (and I assume it is) but I am no where near that yet.

Any advice would be appreciated.

Michael

Re: Passing Parameters with SYS
Post by admin on Sep 14th, 2009, 9:53pm

Quote:
I have been looking for a good C or C++ IDE and compiler

I use gcc, as I think you know; that's what the BB4W IDE is created with. Of course gcc doesn't come with an IDE: it's a command-line utility (but since every C compiler I've ever used has been a command-line utility, that doesn't worry me).

Harking back to the old D3DX8BBC.DLL (or absence thereof) issue, if you want to build DLLs that link in Microsoft Object-Orientated library code you probably have little choice but to use Visual Studio.

Richard.
Re: Passing Parameters with SYS
Post by Michael Hutton on Sep 14th, 2009, 11:40pm

Thanks again Richard. I will have a look and see what I can do.

Michael
Re: Passing Parameters with SYS
Post by knudvaneeden on Sep 15th, 2009, 6:03pm

on Sep 14th, 2009, 2:30pm, Michael Hutton wrote:
On
another note I have been looking for a good C or C++ IDE and compiler
with which I can do exactly what you say. Write fast routines which I
can put in a dll and then call from BB4W and/or look at the ASM output
of the compiler.


Beside Richard's information, I think Jon (Ripley) would be the man to
ask for advice, he is really into C/C++ and DLLs.

---

On Microsoft Windows thus Microsoft Visual Studio (I downloaded a free
Visual Studio C++ express version a while ago, in order to look at
maybe creating this BBCBASIC graphics DLL). Now the possibility to work
with the full (2005 or 2008) version, but not really using that system.

---

Further worked with the GUI C++ Builder (sold to Embarcadero) from
Borland. It should work OK, also creating DLLs via a wizard in the
menu. I looked into creating this BBCBASIC graphics DLL via C++ Builder
(I have that installed), but that process was not really well described
in the (Google) information I found. Because the (graphics) DLL handles specific Microsoft
based information, it showed in this particular case to be better for
compatibility and easy, simple creation to use Microsoft Visual Studio.

---

I work usually myself via my favorite number one programmer's text
editor Semware TSE professional, and compile then the C++ programs via
the command line. I have always used the free Borland C++ command line
compiler for that until now.

C++: Borland: Compiler: Command: Line: Install: How to install free Borland command line compiler?
http://www.knudvaneeden.com/tinyurl.php?urlKey=url000344

I create the programs in the TSE editor
and can automatically invoke a corresponding interpreter or compiler,
e.g. Borland bcc, depending on the file extension (e.g. cpp in this
case).

with friendly greetings
Knud van Eeden
Re: Passing Parameters with SYS
Post by Michael Hutton on Sep 17th, 2009, 02:11am

Thanks Knud,

I have gone for the Visual Studio Express edition and fiddled around with that. I have managed to write a simple console program and get its ASM output which I found very useful. C++ is all rather new this end but I can see a massive potential for creating DLL's for BB4W. I have always been rather frightened of the debugging process in C++, contrary to BB4W which is so easy.

Looking through the output to one program I can see the mov esp,ebp : mov eax,[address of something] being used which is food for thought.

Michael
Re: Passing Parameters with SYS
Post by admin on Sep 17th, 2009, 09:03am

Quote:
I can see a massive potential for creating DLL's for BB4W

Be careful that you don't give BB4W some of the undesirable attributes of Liberty Basic! LB requires the use of 'helper' DLLs because its inbuilt capabilities for doing 'sophisticated' things with the Windows API are very limited. In BB4W, with its embedded assembler, that's not so. I'd need to be convinced that what you envisage doing using a DLL can't practically be achieved using embedded BB4W assembler code.

Richard.
Re: Passing Parameters with SYS
Post by Michael Hutton on Sep 18th, 2009, 12:16am

One of the reasons I would like to be more proficient with C++ was/is to create assembler routines, or rather check my own. I have now been able to look at the output of various programs and have been happy that the disagreeembler code seems to follow very closely the C++ output. I would even say (ahem!) that some of my hand written stuff is actually better,,,I mean, faster than the compiler, but only by using 'shortcuts' or destroying registers and probably doing 'unsafe' things. Which leaves the obvius problem of not being able to integrate them at a latter date without doing the needed saving of registers etc. They are not exactly encapsulated objects. I will try to come up with an example...all are pretty short at the moment and not really worth posting. It is a very interesting excercise. I am particularly intrigued with C++ use of the stack and the definition of entry and exit points from code blocks. { and }.

I hear you warning about the dll 'bloat'. I am not out here to change what isn't broken in BB4W. In fact I entirely agree that a BB4W library file is more than good enough for 99.9..% of applications. But, for example, could GFXLIB be translated to a dll easily? (David, we need a blur routine!!! (and more documentation!!!) - sorry for outburst!) and I think that the GFXLIB_PlotPixelList may need changing because it doesn't like the pixel list to be part of a larger sturcture....ie PointList{()} x%,y%,c%, something, else} ) Also, some colour routine such as the hsvtorgb and vice vesa would be suited to a dll (Yes/no?). Or are they best left as B4W libraries. I would be interested in peoples thoughts.

Also, I have found the idea of having LOCAL variables in different code blocks very good. Could this be a feature added to BB4W? for instance, a FOR.. NEXT loop can have its iterator made local to that code block and other variables declared in it can be made local. I tend to use the static variables (A%-Z%) for local and loop iterators due to their speed.

Anyway, have to go..

Michael
Re: Passing Parameters with SYS
Post by David Williams on Sep 18th, 2009, 01:32am

on Sep 18th, 2009, 12:16am, Michael Hutton wrote:
But, for example, could GFXLIB be translated to a dll easily


I've been working on GFXLIB a lot lately - specifically, I've had another go at trying to modularize it (and I'm actually succeeding this time!). So, except for a small set of commonly used 'core' routines, the programmer would just INSTALL the routines that she requires, viz.:

Code:
INSTALL @lib$+"GFXLIB" : PROCAutoInit32
INSTALL @lib$+"GFXLIBmodules\PlotRotate" : PROCInitModule
INSTALL @lib$+"GFXLIBmodules\BoxBlur3x3" : PROCInitModule
INSTALL @lib$+"GFXLIBmodules\PlotScaleFade" : PROCInitModule
    etc.




on Sep 18th, 2009, 12:16am, Michael Hutton wrote:
(David, we need a blur routine!!!


It has a few now (and some of them are actually employed in Crystal Hunter II -- just hit 'P' for pause during the game to see some blurring):

GFXLIB_BoxBlur3x3
GFXLIB_BoxBlur3x3R
GFXLIB_BoxBlurNxN
GFXLIB_BoxBlurNxNR
GFXLIB_BrushBlur

(The R suffix means 'Replace' - that is, the bitmap to be blurred is replaced by the final blurred bitmap.)

The blurring routines currently suffer from two defects (which I don't intend to fix unless there's popular demand for it (unlikely)):

1. They are comparatively slow
2. The blurring of the edges of a bitmap are not handled as well as they could be, leading to a slight (but often hardly noticeable) darkening around the edges of the bitmap, a few pixels wide).

Please feel free to contribute a Gaussian blur routine, Michael. ;-)


on Sep 18th, 2009, 12:16am, Michael Hutton wrote:
(and more documentation!!!) - sorry for outburst!)


I agree. :)




on Sep 18th, 2009, 12:16am, Michael Hutton wrote:
and I think that the GFXLIB_PlotPixelList may need changing because it doesn't like the pixel list to be part of a larger sturcture....ie PointList{()} x%,y%,c%, something, else} )


Yes, I think you meant PlotPixelList. It wasn't intended to be flexible enough to read coordinates (+ optional colour value) from nested(?) structures - only contiguous blocks of fixed-format data (int X, int Y[, int RGB32]).


David.
Re: Passing Parameters with SYS
Post by admin on Sep 18th, 2009, 09:07am

Quote:
Also, some colour routine such as the hsvtorgb and vice vesa would be suited to a dll (Yes/no?). Or are they best left as B4W libraries. I would be interested in peoples thoughts.

It seems to me that there are two main differences between putting code in a DLL compared with putting it in a BB4W library.

The first is that a DLL will (almost certainly) be written in C or C++, whereas a BB4W library will have to be a mixture of BASIC and assembler.

The second is that with a DLL you don't need to 'ship' the source code, but with a BB4W library you do.

My view is that, in both cases, there's no clear argument as to which is 'better'. Writing in C may be quicker/easier, but the final code may execute more slowly (or it may not). On the other hand a BASIC/assembler hybrid approach can be very powerful, but learning assembler to the required degree of proficiency isn't easy.

As far as incorporating the source code is concerned it can make the 'library' solution rather bloated (although there are ways to avoid the source using up memory at run time, e.g. by CALLing it) but on the other hand it means everything is openly available for any BB4W user to learn from and adapt to his own needs.

I think it's perhaps this last point that I feel most strongly about. Of course if you particularly want your source code to be kept 'secret' then a DLL is the way to go, but then nobody other than you can fix bugs, make improvements etc. I always worry that if the original author loses interest, or drops dead, we could be left with a 'white-elephant' DLL if a bug or incompatibility is discovered.

Richard.