Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2002-11

Assembly routines problem

3 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

andrew johnson

I am porting some low-level(proprietary) components to FPC. They in turn use a unit with some basic scaling routines, which are in assembly..

I know little assembly and DO NOT want to waste my time learning more, but the routines in question will not compile.. so first.. for Delphi assembly compatibility do I have to change assembler mode.. like to AT&T Vs. Intel? 2nd do routines like these already exist in the FPC, so that I can simply get rid of them? The headers declare them(the routines which won't compile) as :

{ Scales up floating point Value into whole integer Value  }
function ScaleUp(Value: Extended; Places: integer): Integer;
{ Scales down whole integer Value into floating point Value }
function ScaleDown(Value: Integer; Places: integer): Extended;
{ Checks double for valid values for 52-bit integer }
function ValidInt52(Value: Double): Boolean;

For the first two I do not understand why floor/ceil aren't being used anyway.. and for the 3rd I do not see what purpose it could possible serve. But since I don't use it directly and I am not familiar enough with the components internals, I cannot say for certain that it will work fine without them.

Anybody help is appreciated.

Andrew

Reply by email

Anton Tichawa
to andrew johnson

hi, andrew!

I know little assembly and DO NOT want to waste my time learning more,

well, I LIKE ASSEMBLER, and i don't consider the time i spent with assembler being wasted ;)

two weeks ago i translated an fpc-procedure for simple graphic rendering to assembly, and it worked great!

it's hard to answer your questions without knowing the codes. i can take a look at it if you want to.

maybe you can try, instead, to rewrite these 3 procedures in pascal and see if and how fast it works?

ciao,

anton

you wrote 33 lines
I am porting some low-level(proprietary) components to FPC. They in turn use a unit with some basic scaling routines, which are in assembly.. but the routines in question will not compile.. so first.. for Delphi assembly compatibility do I have to change assembler mode.. like to AT&T Vs. Intel? 2nd do routines like these already exist in the FPC, so that I can simply get rid of them? The headers declare them(the routines which won't compile) as : { Scales up floating point Value into whole integer Value } function ScaleUp(Value: Extended; Places: integer): Integer; { Scales down whole integer Value into floating point Value } function ScaleDown(Value: Integer; Places: integer): Extended; { Checks double for valid values for 52-bit integer } function ValidInt52(Value: Double): Boolean; For the first two I do not understand why floor/ceil aren't being used anyway.. and for the 3rd I do not see what purpose it could possible serve. But since I don't use it directly and I am not familiar enough with the components internals, I cannot say for certain that it will work fine without them. Anybody help is appreciated. Andrew _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

andrew johnson
to Anton Tichawa
Anton Tichawa wrote 7 lines
hi, andrew! > I know little assembly and DO NOT want to waste my time learning more, well, I LIKE ASSEMBLER, and i don't consider the time i spent with assembler being wasted ;)

thanks.. and more power to you but... I have had a need to use a Assembly for speed only a hand full of times in the past.. so it is a waste given that I am likely to never again use what knowledge I might learn in the process..besides why use assembly when a.) I want cross CPU capabilities, b.) when there is no worthwhile difference in speed(for the stuff I do)? I don't do MMX, or the like, and don't write drivers or the like.. and I am not involved in anything like the RTL or FCL which might need it to supply the Cross-Platform/CPU stuff. but anyway..

two weeks ago i translated an fpc-procedure for simple graphic rendering to assembly, and it worked great!

I tried adding {$ASMMode Intel} and the stuff compiled.

it's hard to answer your questions without knowing the codes. i can take a look at it if you want to.

like I said proprietary.. don't know what all the license says about that sort of thing, else I would have posted the actual code to one of the smaller ones.

maybe you can try, instead, to rewrite these 3 procedures in pascal and see if and how fast it works?

I would love to convert it to pascal or better yet throw it out the window..but I don't know what it does.. and cannot understand the asm behind it. oh well.. I will continue to work on the rest of the components and get everything working then come back to this and see if I can't rip the code out entirely.

Show quoted text 36 lines
ciao, anton On Wednesday 13 November 2002 19:07, you wrote: > I am porting some low-level(proprietary) components to FPC. They in turn > use a unit with some basic scaling routines, which are in assembly.. > > but the routines in question will not compile.. so first.. for Delphi > assembly compatibility do I have to change assembler mode.. like to AT&T > Vs. Intel? 2nd do routines like these already exist in the FPC, so that > I can simply get rid of them? The headers declare them(the routines > which won't compile) as : > > { Scales up floating point Value into whole integer Value } > function ScaleUp(Value: Extended; Places: integer): Integer; > > { Scales down whole integer Value into floating point Value } > function ScaleDown(Value: Integer; Places: integer): Extended; > > { Checks double for valid values for 52-bit integer } > function ValidInt52(Value: Double): Boolean; > > > For the first two I do not understand why floor/ceil aren't being used > anyway.. and for the 3rd I do not see what purpose it could possible > serve. But since I don't use it directly and I am not familiar enough > with the components internals, I cannot say for certain that it will > work fine without them. > > Anybody help is appreciated. > > Andrew > >

Well thanks anyway!

Andrew

Reply by email