flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > High Level Languages > Getting Comfortable with Standard C

Author
Thread Post new topic Reply to topic
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
Getting Comfortable with Standard C
std C

Code:

void zline_3(SDL_Surface *_screen,int x0int y0int x1int y1,Uint16 _color)
{ // demonstration of functional polymorphism #3
float slopej=0;
int dx=abs(x1-x0), dy=abs(y1-y0);
int sx=(x0 < x1)?1:-1sy=(y0 < y1)?1:-1;
int f=(dx >= dy)?1:0k=(f)?dx:dyc=(f)?sx:syd=(f)?sy:sxi;
slope=(float)(d)*((f)?(float)dy/(float)dx:(float)dx/(float)dy);
    for (i=0;abs(i)<=k;i+=c)
    {
    setpixel(_screen,x0+f*i+(f^1)*round(j),y0+f*round(j)+(f^1)*i,_color);
    j+=slope;
    }
}



macros in std C

Code:

#define __clone____clone__to__clone__from )   __typeof__ (__clone__from)  (__clone__to) = (__clone__from)

//  macro var name vs last level variable collision
#define lroundfz_float_t_ ) ({                                    \
    float_t  f = (float_t)(_float_t_);                          \
    int64_t __tf__ = truncf(f);                                 \
    float_t  __fz__ = ( f - (float_t)__tf__ );                  \
    int32_t result,                                                 \
              __y__ = ( __fz__ > 0.0 ) - ( __fz__ < 0.0 ),          \
              __z__ = ( ( __fz__ *  __y__ ) >= ( 0.5f ) ) * __y__;  \
   result = ( __tf__ + __z__ );                                     \
   result;                                                          \
})

// rasterize a line on screen with starting position p1 (x0,y0), ending position p2 (x1,y1), draw with color
void zline_5(voidsp2f_t ip1p2f_t ip2uint32_t icolor)
{ // demonstration of functional polymorphism #5    //  multiply version
__clone__(p1ip1); __clone__(p2, ip2); __clone__(color, icolor);
float dx = fabsfp2.x - p1.x ), dy = fabsfp2.y - p1.y );
int sx = ( p1.x < p2.x )?1:-1sy = ( p1.y < p2.y )?1:-1f = ( dx >= dy )?1:0c = (f)?sx:syd = (f)?sy:sxi;
float k = (f? dx : dyslope = (float)(d) * ( (f? dy / dx : dx / dy);
  for ( i = 0; abs(i) <= k; i += c ) {
  float   absis = abs(i) * slope;
  putpixel(slroundfz(p1.x + (f^1) * absis) + f * ilroundfz(p1.y + f * absis) + (f^1) * icolor);
  }
}




(had to disable smilies because it was parsed in codeblock)
Feel free to contribute if you have something to say...
Post 19 Oct 2014, 13:52
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14469
Location: ?                               Posts: 6699
Why is it that C programmers like to use single letter variable names? i, j, f, z, y, x, c, d, g, i2, c5 etc. They communicate no information to the reader IMO and server to confuse things more.

Let's have a campaign against the use of short and uninformative variable names. Let's be more verbose and communicate more to the reader. It's not like there isn't enough disk space to store the source code or something.

[/rant]
Post 19 Oct 2014, 14:00
View user's profile Send private message Visit poster's website Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow

revolution wrote:
Why is it that C programmers like to use single letter variable names? i, j, f, z, y, x, c, d, g, i2, c5 etc. They communicate no information to the reader IMO and server to confuse things more.

Let's have a campaign against the use of short and uninformative variable names. Let's be more verbose and communicate more to the reader. It's not like there isn't enough disk space to store the source code or something.

[/rant]



Only did that because it was short, and locally this does not matter, those are just random temporary variables.
Post 19 Oct 2014, 14:03
View user's profile Send private message Visit poster's website Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
More Macronizing Abstraction
More Macronizing Abstraction

So what is written in a macro will be computed at compile time,
Macro(s) can be passed to Macro(s) as input(s) so if you write a Matrix Multiplication that can be computed at compile time because you are just lazy to precalculate, it -may- be compiled as a constant.

(added inverse 2x2 matrix macro)


Code:



I think Tomasz will like this :)
Post 19 Oct 2014, 14:23
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1173
Location: Unknown
Stupid post removed.


Last edited by HaHaAnonymous on 28 Feb 2015, 17:51; edited 1 time in total
Post 27 Feb 2015, 01:10
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14469
Location: ?                               Posts: 6699
The most time that you can ever save is during the initial write phase. Taking a small amount of extra time at the beginning will save more time later when you come back to the code after 12 months and wonder what hell you were doing.

Or put another way; thinking and writing a longer more descriptive variable name does take a modicum of extra time initially. But saves you more when you have to go back through all of it again a year later when you need to change something.
Post 27 Feb 2015, 01:33
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1173
Location: Unknown
Stupid post removed.


Last edited by HaHaAnonymous on 28 Feb 2015, 17:51; edited 1 time in total
Post 27 Feb 2015, 02:00
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 493
Location: New Zealand

HaHaAnonymous wrote:

Quote:

when you come back to the code after 12 months and wonder what hell you were doing.


The solution for this is documentation.

In the documentation you can describe how your program works, what every single function does and why.

Apart from that, we also have comments. But it is annoying when you have more comments than actual code in your source (that is where the documentation shines).

Just my opinion.

The best documentation is automatically created by well-written self-documenting source e.g. by using meaningful variable names Razz imo

_________________
FAMOS - the first memory operating system
Post 27 Feb 2015, 02:08
View user's profile Send private message Visit poster's website Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000

HaHaAnonymous wrote:
The solution for this is documentation.



Have you worked on any big projects?


neville wrote:
The best documentation is automatically created by well-written self-documenting source e.g. by using meaningful variable names Razz imo



This


Last edited by typedef on 27 Feb 2015, 04:52; edited 2 times in total
Post 27 Feb 2015, 03:29
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14469
Location: ?                               Posts: 6699
typedef: Stop misquoting me. I already asked you to stop in another thread.
Post 27 Feb 2015, 03:35
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1173
Location: Unknown
Stupid post removed.


Last edited by HaHaAnonymous on 28 Feb 2015, 17:50; edited 1 time in total
Post 27 Feb 2015, 03:55
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000
@revolution
Lol. Sorry, I forgot to take my meds. Quoted wrong person hhaha Very Happy

Feel free to edit my posts.
Post 27 Feb 2015, 04:50
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14469
Location: ?                               Posts: 6699

HaHaAnonymous wrote:
The solution for this is documentation.

Since when do programmers ever read documentation to understand the code? Confused

The purpose of documentation is to confuse the end users and make them feel stupid.

Code:
;...
proc f356 p1,p2,p3,p4 ;documentation for this function is on page 49
;code with no comments goes here
endp

proc f357 p1,p2,p3,p4,p5 ;documentation for this function is on page 13
;code with no comments goes here
endp
;...

And naturally the page numbers do not correlate with the document because they are edited on different schedules.
Post 27 Feb 2015, 05:06
View user's profile Send private message Visit poster's website Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 244
Location: Australia
Felt the need to chime in here, haha

I have written a fair amount of code that starts with a description of what the function does, and then proceed to write uncommented (and to the casual observer, difficult to follow) assembler (or C, C++, Java, Javascript, etc).

In the context of your macro expansion/confusion in C, since indeed most of those variables are indeed "random temporaries", would the code be easier to read if they were all temp1, temp2, temp3, temp4... etc?

I submit that it would not, and that a,b,c,d or x,y,z is just as easy to comprehend (if comprehension was indeed part of the original design spec).

As is often the case with purely mathematic constructs, it is up to the reader to make sense of what all those mysterious x, y, z's are, and not up to the person who came up with the equation to begin with.

IMO, code is not far off this mark Smile If the input/output of a given function is clearly documented, then in many cases (especially where naming temporaries, registers, etc is not possible OUTSIDE THE CONTEXT OF EDUCATION [emphasis added, haha]), commenting and naming variables inside said function isn't really required.

That said, if the purpose of the function is for people to learn about what is actually happening, then x,y,z doesn't work at all, nor do register names or poorly documented code (that I am also guilty of).

Smile

$0.02 thusly
Post 27 Feb 2015, 06:46
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
There are cases where x,y,z and i,j,k are descriptive enough. The former are good for (surprise-surprise!) coordinates, though in some cases those need to be more specific such as xMov or xPos. And the latter are generally acknowledged as indices starting with i, which is a direct abbreviation of the word, and j,k for the cases of naming clashes.

Most important is however the documentation directly embedded into the inline comments, which is especially true for assembly code, where I normally write a description to the right of instructions for each value placed into a register.

_________________
Faith is a superposition of knowledge and fallacy
Post 27 Feb 2015, 14:30
View user's profile Send private message 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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.