flat assembler
Message board for the users of flat assembler.

 Index > Main > Getting started "this way" Goto page Previous  1, 2
Author
tthsqe

Joined: 20 May 2009
Posts: 767
tthsqe 26 Nov 2013, 21:23
Code:
```SquaredDistanceEstimate:  ; plotting F(x,y)=0
; given x at xmm0 and y at xmm1 (double precision), this should return F(x,y)^2/(gradF(x,y).gradF(x,y)) in xmm0 (single precision)
; for F(x,y) = x^2+a y^2-1, this is (x^2+a y^2-1)^2/((2x)^2+(2a y)^2)
mulsd  xmm0,xmm0
mulsd  xmm1,xmm1
mulsd  xmm1,[a]
movsd  xmm2,xmm1
mulsd  xmm2,[a]
...
.l2:    movsd  xmm0,[xmax]
movsd  xmm1,[ymax]
cvtsi2sd  xmm2,edi
cvtsi2sd  xmm3,esi
mulsd  xmm2,[xstep]
mulsd  xmm3,[ystep]
subsd  xmm0,xmm2     ; x
subsd  xmm1,xmm3     ; y
call  SquaredDistanceEstimate
...    ```

The sse registers are never really 'empty', they just have unknown contents. My comment at the beginning of SquaredDistanceEstimate means that before you call it, you should put the arguments x and y in xmm0 and xmm1, as I did in the second block where I do call it.
26 Nov 2013, 21:23
schlukhash

Joined: 07 Nov 2013
Posts: 9
schlukhash 27 Nov 2013, 13:52
Ah that did clear that up for me, Going to pick at it some more in a bit. thanks!

@ Edfed: http://www.schlukhash.nl/index.php/thesis-vst
Been tweaking this for the last year.
Think it would be nice to have al the functional parts as classes. Or better yet an open assembly based sdk. Seeing skins are actually a more creative and intuitive thing. And dsp is fine in assembly.

To be more specific, the granular engine, lfo and functional parts I have in my portfolio as assembly macros, and i have prodominantly synthesis routines in my files. The skin is something I can design and human engineer, but have zero skills implementing in any sdk. So its a bit too focused on writing synthesis routines

Actually a good open asm dll in dll sdk is what im dreaming of, (all black for a change) .
27 Nov 2013, 13:52
edfed

Joined: 20 Feb 2006
Posts: 4330
Location: Now
edfed 28 Nov 2013, 09:43
coollllll! now i know i can test vst, then, i can code vst too.

if you want i can join you in the vst development, in asm and maybe in c++ too (but i prefer in asm).

your thesis vst is a good start i think if we want it in asm, we first should extract the functionning diagram, and then traduce it in asm.

i don't have a lot of time for this, but i will really enjoy to code vst.
we can discuss about it later if you want.

 Description: how it looks like in fruity loops. awsome!!! Filesize: 146.89 KB Viewed: 5612 Time(s)

28 Nov 2013, 09:43
schlukhash

Joined: 07 Nov 2013
Posts: 9
schlukhash 30 Nov 2013, 14:39
Glad you like it I was pondering to make it free one of these days.
The release version is way more versatile, and optimised Not that it really matters tho.

Was actually thinking about a compiler, will up some sketches probbably tuesday when the rest is layed out, maybe if theres interest i can start an opensource project/forum. But it all depends offcourse.
30 Nov 2013, 14:39
whakamaru

Joined: 03 Oct 2012
Posts: 20
Location: New Zealand
whakamaru 22 Dec 2013, 22:37
I am confident that my logic and syntax is (or are) correct, but I don't seem to be able to get a usable file. Yes I've looked at the documentation and all the examples in both fasm-for-dos and for windows. it is the instructions to fasm itself that I can't get right.
All I am trying to do is write programs that will solve Project Euler problems, ie, simple (!) add, subtract etc. not fancy display. I wrote a solution for PE#5. If I put it within the USEDPMI example, it compiles, runs and gives the correct answer, but if I try to get it as a stand-alone program, I get a message from "16-bit MS-DOS subsystem". Well of course, a 32-bit program won't go. So, my directives to FASM must be wrong.
How should I FORMAT etc?
2. Which FASM should I be using, for DOS? or Windows?
The windows examples look so complicated when all I am doing is calculating and display the answer?
3. I tried to write a 64-bit program. It compiles OK, but when I look at the machine code, I see that
mov rax,1000000000 compiles correctly to the correct hex values, but
mov rax,1000000000000000 doesn't? 8 bytes are allocated, including two zeros, but they are not the correct hex values? 64-bits should cope with a much bigger number?
4. The USEDPMI solution for PE#5 which runs OK from both the C: promplt and from the windows file on my 32-bit PC. But trying the run the same program on a 64-bit PC gets a message.... "contact your software people and get a proper 32 or 64-bit program. so... what directives should I try to get FASM to compile a 64-bit program?
22 Dec 2013, 22:37
neville

Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville 23 Dec 2013, 04:42
whakamaru - Greetings and welcome, fellow kiwi!

I haven't dabbled with 64-bit stuff for quite a while so hopefully somebody else will help you, but iirc x86-64 CPU's don't generally support 64-bit immediate operands. Yes, I know, you would expect any self-respecting CPU that claims to be 64-bit to natively support an instruction to load a 64-bit immediate value into a 64-bit register. But apparently not...

_________________
FAMOS - the first memory operating system
23 Dec 2013, 04:42
HaHaAnonymous

Joined: 02 Dec 2012
Posts: 1178
Location: Unknown
HaHaAnonymous 23 Dec 2013, 04:57
[ Post removed by author. ]

Last edited by HaHaAnonymous on 28 Feb 2015, 18:55; edited 1 time in total
23 Dec 2013, 04:57
alessandro95

Joined: 24 Mar 2013
Posts: 62
alessandro95 23 Dec 2013, 08:02
MOV is one of the few instructions that supports imm64 operands,I had the same problem trying to multiplicate by big immediates and I had to MOVe them somewhere before the multiplication, so your code should be fine
23 Dec 2013, 08:02
m3ntal

Joined: 08 Dec 2013
Posts: 296
m3ntal 24 Dec 2013, 09:24
neville:
Quote:
you would expect any self-respecting CPU that claims to be 64-bit to natively support an instruction to load a 64-bit immediate value into a 64-bit register. But apparently not
ARM and MIPS have fixed-width instructions - for the best optimizations: table[i] - and they are meant for pure register usage (see Magic-ARM compiler). 32/64/128BIT immediates can be loaded from IP relative literal tables in 1 instruction. X86 may be easier and more convenient for the programmer, but ARM has the greatest performance. No CPU design is perfect, though.
24 Dec 2013, 09:24
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20218
revolution 24 Dec 2013, 09:34
neville wrote:
... x86-64 CPU's don't generally support 64-bit immediate operands. Yes, I know, you would expect any self-respecting CPU that claims to be 64-bit to natively support an instruction to load a 64-bit immediate value into a 64-bit register. But apparently not...
The problem is encoding space.

How would one encode this?:
Code:
`add rax, [rbx + rcx * 0x123456789abcdef0 + 0x123456789abcdef0], 0x123456789abcdef0    `
There has to be a limit somewhere else you get ridiculously long instruction encodings making the whole CPU decoder take a disproportionately large silicon area and costing a disproportionately large amount of performance issues.
24 Dec 2013, 09:34
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First

 Jump to: Select a forum Official----------------AssemblyPeripheria General----------------MainTutorials and ExamplesDOSWindowsLinuxUnixMenuetOS Specific----------------MacroinstructionsOS ConstructionIDE DevelopmentProjects and IdeasNon-x86 architecturesHigh Level LanguagesProgramming Language DesignCompiler Internals Other----------------FeedbackHeapTest Area
Goto page Previous  1, 2

Forum Rules:
 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum