flat assembler
Message board for the users of flat assembler.

Index > High Level Languages > Sphinx C--

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 23 Sep 2011, 20:35
Quote:
which is more readable , using invoke macro or calling a function like a high level language do ?
neither, it's an extremely small syntactic difference.

Quote:
which is more readable , declaring variables with (DB , DW , and DD) or with a high level language do ?
the high-level way, since it gives semantic information and not just size.

Quote:
which is more readable , using arguments inside the procedure with EBP indexed or with the normal name
Well, [EBP+varname] is as readable as [varname], but [ebp+42] obviously isn't.

Quote:
which is more readable , this expretion mov EAX,5 or EAX = 5; ?
Neither, it's an extremely small syntactic difference.

Quote:
the point here is not the fast code to be generated by Sphinx C--,
If you're dropping to assembly and your purpose isn't to make things faster, you're doing things wrong. Outside of very limited domains, you don't get better readability/maintainability. I know a bunch of crackheads here are going to disagree, based on either utter stubbornness or extremely limited exposure to only very bad code samples from a single HLL... the rest of us have moved on, and use assembly where it matters.

Quote:

Sphinx C-- allows you to mix asm low level code with C high level code , so you can make a code that
is more faster easlly by using directlly SSE instructions.
The sane thing to do is use whatever HLL for the bulk, and link to an external asm (very likely fasm!) module fro the parts where it matters. Productivity AND performance, that's the way to go.
Post 23 Sep 2011, 20:35
View user's profile Send private message Visit poster's website Reply with quote
me239



Joined: 06 Jan 2011
Posts: 200
me239 23 Sep 2011, 21:03
Sphinx C-- can be ported. You just have to have different header files... much like c++.
Post 23 Sep 2011, 21:03
View user's profile Send private message Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 570
Location: Brazil
Teehee 23 Sep 2011, 23:26
i would like it if instead C/C++ syntax it would use a cleaner syntax as C#.
Post 23 Sep 2011, 23:26
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1694
Location: Toronto, Canada
AsmGuru62 24 Sep 2011, 00:04
Yep, that is what I am trying to build right now.
Mixed FASM with some HL constructs, like classes and such.
Post 24 Sep 2011, 00:04
View user's profile Send private message Send e-mail Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 570
Location: Brazil
Teehee 24 Sep 2011, 00:25
cool, do not let to show us the progress.
Post 24 Sep 2011, 00:25
View user's profile Send private message Reply with quote
emil



Joined: 16 Dec 2003
Posts: 76
Location: egypt
emil 24 Sep 2011, 06:07
@ f0dder:

when coding with asm , it is your responsibility to generate a fast or slowe code. the full control is in your hand.
consider the first Examole , which is faster in your opinion strlen1 procedure or strlen4 one ?

note well , strlen4 does not emil stack frame but strlen1 does.

the two procedures mead with Sphinx C-- ,but have deferent speed .hope you get me now.

@ me239:

Sphinx C-- can make COFF and OMF object format , which means that you can ues MASM linker , Borland C++ linker ,
or MinGW linker. so you can port it to any operating system that you wish.

@ Teehee:
Sphinx C-- has some C++ features , so here is a small demo that came with Sphinx C--

class.h-- file
Code:

#define class struct

#ifdef __TLS__
#include <windows.h-->

:dword fastcall __new(EAX)
{
     return GlobalAlloc(GMEM_FIXED,EAX);
}

:dword fastcall __delete(EAX)
{
    IF(EAX)GlobalFree(EAX);
}

#endif

#ifdef __MSDOS__
#include "alloc.h--"

:word fastcall __new(AX)
{
     return MALLOC(AX);
}

:word fastcall __delete(AX)
{
       IF(AX)FREE(AX);
}

#endif
    


test.c-- file
Code:
#pragma option w32c
#include "winbase.h--"
#include "class.h--"
#include "msvcrt.h--"
struct info {
   info(dword str);
    ~info();
    char buf[80];
};

info::info(dword str)
{
     IF(this){
              strcpy(#buf,str);
           printf("%s%s\n","Create class in ",#buf);
      }
      return this;
}

info::~info()
{
       printf("%s%s\n","Destroy class in ",#buf);
}

info ss;

int CheckClass()
{
info s1;
dword w1;
        w1 = new info("allocate memory");
 s1.info("stack memory");
  ss.info("programm memory");
       delete ss;
  delete w1 info;
}

void main()
{
      CheckClass();
}
    



@ AsmGuru62 there was an Example in Sphinx C-- that showing you how to mix FASM and Sphinx C-- , i will post
it later.
Post 24 Sep 2011, 06:07
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 25 Sep 2011, 15:03
me239 wrote:
Sphinx C-- can be ported. You just have to have different header files... much like c++.
How would that help your 32bit x86 code running on x86-64, or ARM? Smile

emil wrote:
when coding with asm , it is your responsibility to generate a fast or slowe code. the full control is in your hand.
consider the first Examole , which is faster in your opinion strlen1 procedure or strlen4 one ?
Depends on the input string length - personally, I use std::string and get O(1) length lookups - no assembly involved, no hacks required Smile
Post 25 Sep 2011, 15:03
View user's profile Send private message Visit poster's website Reply with quote
me239



Joined: 06 Jan 2011
Posts: 200
me239 03 Oct 2011, 21:33
f0dder wrote:
me239 wrote:
Sphinx C-- can be ported. You just have to have different header files... much like c++.
How would that help your 32bit x86 code running on x86-64, or ARM? Smile
Maybe you didn't understand what I meant by porting. What I meant is that you can code applications to run on DIFFERENT systems, not the compiler. So actually in that manner it is exact to C++.
Post 03 Oct 2011, 21:33
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 04 Oct 2011, 05:39
me239 wrote:
f0dder wrote:
me239 wrote:
Sphinx C-- can be ported. You just have to have different header files... much like c++.
How would that help your 32bit x86 code running on x86-64, or ARM? Smile
Maybe you didn't understand what I meant by porting. What I meant is that you can code applications to run on DIFFERENT systems, not the compiler. So actually in that manner it is exact to C++.
And that doesn't help with regards to portability of your applications - at best you get a cross-compiler.

_________________
Image - carpe noctem
Post 04 Oct 2011, 05:39
View user's profile Send private message Visit poster's website Reply with quote
me239



Joined: 06 Jan 2011
Posts: 200
me239 06 Oct 2011, 19:34
[quote="f0dder"][quote="me239"]
f0dder wrote:
And that doesn't help with regards to portability of your applications - at best you get a cross-compiler.
Um... I have no idea what you mean. An application is written for the platform it was designed to run on. C++ should work the same way. A compiled Windows application will not work on Mac OSX w/o emulation will it?
Post 06 Oct 2011, 19:34
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 06 Oct 2011, 20:10
me239 wrote:
Um... I have no idea what you mean. An application is written for the platform it was designed to run on. C++ should work the same way. A compiled Windows application will not work on Mac OSX w/o emulation will it?
You'll never get 100% portability, and you aren't going to get major-platform portability without writing some OS-specific code (or targeting a REALLY low lowest-common-denominator).

But there's ways you can make large parts of your applications portable - writing OS- and CPU-specific code in your core parts is not the way to achieve that. If you're going to use a HLL, why use one that doesn't give you much advantage over assembly?

_________________
Image - carpe noctem
Post 06 Oct 2011, 20:10
View user's profile Send private message Visit poster's website Reply with quote
me239



Joined: 06 Jan 2011
Posts: 200
me239 07 Oct 2011, 21:34
f0dder wrote:
You'll never get 100% portability, and you aren't going to get major-platform portability without writing some OS-specific code (or targeting a REALLY low lowest-common-denominator).

But there's ways you can make large parts of your applications portable - writing OS- and CPU-specific code in your core parts is not the way to achieve that. If you're going to use a HLL, why use one that doesn't give you much advantage over assembly?
Once again man, C++ when compiled works the EXACT SAME WAY AS ASSEMBLY. All code is eventually turned into assembly and with compiled C++ and assembly it's immediate. So unless you have a C++ interpreter running C++ code you will have 0% portability, so in the end the two really come out to the same product.
Post 07 Oct 2011, 21:34
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 07 Oct 2011, 22:48
me239 wrote:
]Once again man, C++ when compiled works the EXACT SAME WAY AS ASSEMBLY. All code is eventually turned into assembly and with compiled C++ and assembly it's immediate. So unless you have a C++ interpreter running C++ code you will have 0% portability, so in the end the two really come out to the same product.
Assuming you're not trolling:

there's several aspects of 'portability'. You're describing binary portability, which is what .NET and Java mostly handle (100% is kinda a pipedream, since different hardware has different input and display mechanisms - but it's close).

Then there's source portability, which is what C and C++ offers. Yes. you'll have to build your application for each platform, but if you can reuse, say 90% of your code... that's better than the 100% rewrite you'd need with assembly Smile

_________________
Image - carpe noctem
Post 07 Oct 2011, 22:48
View user's profile Send private message Visit poster's website Reply with quote
me239



Joined: 06 Jan 2011
Posts: 200
me239 08 Oct 2011, 03:01
f0dder wrote:

Then there's source portability, which is what C and C++ offers. Yes. you'll have to build your application for each platform, but if you can reuse, say 90% of your code... that's better than the 100% rewrite you'd need with assembly Smile
YES!!!! That is exactly what I've been trying to tell you!!! All you need to do is rewrite or download a new library, EXACTLY LIKE C++!!! You don't HAVE to use assembly in Sphinx C-- code, only in the functions libraries. So if you rewrite your functions, your code is COMPLETELY PORTABLE! Really the only difference between C++ and Sphinx is the fact you write your OWN libraries and is more compact!
Post 08 Oct 2011, 03:01
View user's profile Send private message Reply with quote
emil



Joined: 16 Dec 2003
Posts: 76
Location: egypt
emil 08 Oct 2011, 17:16
Hi All

here is another demo to show you the easy way of programing with Sphinx C--.

the next code is a simple way to call DirectX9 (COM interface) without using any macro.

the idea is after creating Directx9 Device , i extract each method pointer of it and save it in a pointer table then later i call each method from that table directlly.

also i put helper procdures to make things more simplify.

Code:

// extracting Dx9 methods
GetComProc(EBX,ECX,EDI) 
{
  EBX = DSDWORD[EBX];
  FOR(EAX=0; EAX<EDI; EAX+=4)
   {  
      EDX = DSDWORD[EBX + EAX]; 
      DSDWORD[ECX + EAX] = EDX;
   }  
}

GetDX9Proc(EBX,ECX) 
{
  GetComProc(EBX,ECX,sizeof(IDirect3DDevice9));  
}


// Directx9 class stuff
struct DirectX9 : IDirect3DDevice9
{
   DWORD  InitD3D(dword hWnd);
   void   ReleaseD3D();
   void   _BiginScene(DWORD color);
   void   _EndScene();
     
   static DWORD  D3D; 
   static DWORD  D3DDevice;
   static D3DPRESENT_PARAMETERS d3dpp;
   static DWORD  HWnd;
   static long nScreenWidth = 512;
   static long nScreenHeight = 512;
   
   static char szLogFile[1024]={0};  
};

DWORD DirectX9::InitD3D(dword hWnd) 
{
    
    D3DDISPLAYMODE d3ddm;
    
    DWORD qualityLevels = 0;
    
    IF(hWnd==NULL)
     {
       HWnd = GetActiveWindow();
     }
    ELSE
     {
       HWnd = hWnd;
     } 
    
     D3D = Direct3DCreate9(D3D_SDK_VERSION);
     IF (D3D==0)
         return;
      
   EBX = D3D; EBX = DSDWORD[EBX];
      EBX.IDirect3D9.GetAdapterDisplayMode(D3D, D3DADAPTER_DEFAULT, #d3ddm );

 EAX=#d3dpp;
 RtlZeroMemory(EAX, sizeof(D3DPRESENT_PARAMETERS));
  d3dpp.Windowed=TRUE;
        d3dpp.BackBufferWidth        = nScreenWidth;
        d3dpp.BackBufferHeight       = nScreenHeight;
        d3dpp.BackBufferFormat       = d3ddm.Format;
        d3dpp.EnableAutoDepthStencil = TRUE;
        d3dpp.AutoDepthStencilFormat = D3DFMT_D16;
        d3dpp.BackBufferCount        = 1;
    d3dpp.MultiSampleType        = D3DMULTISAMPLE_NONE;
 d3dpp.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;
 
    EBX = D3D; EBX = DSDWORD[EBX];
      EBX.IDirect3D9.CheckDeviceMultiSampleType(D3D,D3DADAPTER_DEFAULT,D3DDEVTYPE_HAL,d3dpp.BackBufferFormat,FALSE,D3DMULTISAMPLE_2_SAMPLES,#qualityLevels);
        d3dpp.MultiSampleType    = D3DMULTISAMPLE_2_SAMPLES;
      d3dpp.MultiSampleQuality = qualityLevels-1; 
        d3dpp.SwapEffect         = D3DSWAPEFFECT_DISCARD; 
   
   EAX=#d3dpp;

     EBX = D3D; EBX = DSDWORD[EBX];
      EBX.IDirect3D9.CreateDevice(D3D, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, EAX, #D3DDevice);

       IF  (EAX!=D3D_OK){
             XOR EAX, EAX
                RETURN;
            }

    GetDX9Proc(D3DDevice,this);  
}

void DirectX9::ReleaseD3D()
{
       
            IF(D3DDevice != 0) 
          {
                     EBX = D3DDevice; EBX = DSDWORD[EBX];
                        EBX.IDirect3DDevice9.Release(D3DDevice);
                    D3DDevice = 0;
               }
        
         IF(D3D != 0)
                 {
                     EBX = D3D; EBX = DSDWORD[EBX];
                      EBX.IDirect3D9.Release(D3D);
                        D3D = 0;
             }
}

void  DirectX9::_BiginScene(DWORD color)
{
             EBX = D3DDevice; EBX = DSDWORD[EBX];
         EBX.IDirect3DDevice9.Clear(D3DDevice, 0, 0, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, color, 1.0f, 0);
            EBX = D3DDevice; EBX = DSDWORD[EBX];
        EBX.IDirect3DDevice9.BeginScene(D3DDevice);
}

void  DirectX9::_EndScene()
{
             EBX = D3DDevice; EBX = DSDWORD[EBX];
             EBX.IDirect3DDevice9.EndScene(D3DDevice);
           EBX = D3DDevice; EBX = DSDWORD[EBX];
        EBX.IDirect3DDevice9.Present(D3DDevice,NULL, NULL, NULL, NULL);
}


    


here we can use it like that

Code:


Render()
{
    Dx9._BiginScene(RGBA_MAKE(0,0,255,255));
    
    Dx9.SetStreamSource(Dx9.D3DDevice, 0, D3DVB, 0, sizeof(CUSTOMVERTEX));

    Dx9.SetFVF(Dx9.D3DDevice, D3DFVF_XYZRHW | D3DFVF_DIFFUSE );

    Dx9.DrawPrimitive(Dx9.D3DDevice, D3DPT_TRIANGLELIST, 0, 1 );

    
    Dx9._EndScene();
    
}

    
Post 08 Oct 2011, 17:16
View user's profile Send private message Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1166
Location: Overflow
Matrix 04 Nov 2011, 16:25
yeah it was cool to see a real C compiler working with examples on dos in 2001
that was before i started FASM, but already was using inline assembly, and extra operations Smile ( db )

But since linux has gcc and g++ i'm not amazed of it anymore ;/
i have multiple GigaBytes of C/C++ sources now i can compile...
Post 04 Nov 2011, 16:25
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< 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-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.