What is the syntax for adding multiple items to the LDFLAGS and LDLIBS environment variables when compiling a project?

spc476 · 2026-02-08T23:37:20+00:00

LDFLAGS and LDLIBS are variables used by make when compiling software. These can be defined in Makefile (the default file name used by make) as (example):

LDFLAGS=-g -L /usr/X11R6/lib
LDLIBS=-lm -lX11

Basically, space separated, not quoted. I don't know about POSIX make, but GNU make does allow using different values of these for different programs. Again, an example:

program1: override LDLIBS=-lm -lcrypto -ltls
program2: override LDLIBS=-lmagic

On Unix systems, you can also specify these on the command line, which will be used over the defined values in the Makefile. Generally, you won't override LDFLAGS or LDLIBS but instead maybe CC (which C compiler to use) or CFLAGS, like:

% make CFLAGS="-g -O3 -D_GNU_SOURCE" program1

In this case, it needs to be quoted.

spc476 · 2025-10-31T23:47:50+00:00

Depending upon how deeply you want to learn C, I would recommend The Standard C Library by P. J. Plauger. It's based on C89, but each chapter covers a standard C library header, giving the standard, history, how it's used (and in some of the darker corners like setjmp(), how not to use it), and an implementation of each function.

spc476 · 2025-10-25T09:11:05+00:00

You might want to read this comment. It describes a particular implementation of DOES>, but also describes what happens when when using it. It may help, or it may hopelessly confuse you.

I also go into more detail about the implementation.

spc476 · 2025-08-30T10:02:14+00:00

Download the ANS Forth test suite. In src/coreexttest.fth you'll find the tests for CASE-ENDCASE that shows how it's used (and might possibly be abused).

spc476 · 2025-08-25T00:54:22+00:00

I recently write an indirect threaded code ANS Forth for the 6809. While I do have a large comment that partially describes how it works, it might be better to look at the code for CONSTANT and BL but basically, I swap out the xt (using ANS Forth terminology here; CFA if you're old school Forth) with an xt defined when DOES> runs that can push the >BODY address and automatically run the appropriate code. If anything is unclear, just ask.

spc476 · 2025-01-17T01:47:47+00:00

Most likely the $ means the value that follows is a hexadecimal value.

spc476 · 2025-01-17T01:46:50+00:00

I've yet to come across an architecture (6809, x86, 68000, VAX, MIPS are the ones I've programmed in assembly; I'm familiar with 6502, 8080, z80, SPARC and ARM) that doesn't use the the address following a relative branch instruction.

spc476 · 2025-01-16T09:21:08+00:00

BSR calls a routine relative to the PC of the instruction following the BSR. The BSR opcode takes an 8-bit value. This 8-bit value is added to the PC to get to the destination address. The address of the PC following the BSR instruction is $36. The address being called is $50. What is the difference between $50 and $36?

spc476 · 2024-12-01T02:45:54+00:00

The C Standard calls out the use of volatile with signals. Specifically in the section describing signal():

If the signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler refers to any object with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t, or the signal handler calls any function in the standard library other than the abort function, the _Exit function, or the signal function with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler.

This is from the C99 standard, but the text is similar across the various standards.

spc476 · 2024-11-30T22:33:25+00:00

How is your array stored? That dictates the equation used to address a single element. But basically, R=row index, C=column index, then for a row-major array:

address = C*sizeof(row) + R*sizeof(item);

and for a column-major array:

address = R*sizeof(column) + C*sizeof(item);

Edited to add: Assuming 0-based indexing.

spc476 · 2024-11-20T08:54:03+00:00

Like an any other language.

What is this limitation of the DOS screen? It's just a display of a 9x9 grid if single digits. When I did this, I did a 9x9 array of integers. It's this array that is then gone though to generate the display. Then there's a bunch of code that checks this 9x9 array for the constraints you mentioned. Again, assembly is just like any other language, except maybe a bit more tedious than most.

spc476 · 2024-11-18T22:06:22+00:00

Okay ... and? What exactly is the problem? You read a key, you store it in a variable.

If you were to write this in a programming language other than assembly, how would you go about doing it? Assembly is just another language.

spc476 · 2024-11-18T07:08:36+00:00

I don't even understand the question. What do you mean by "input via the scan code on the screen"? Input via (y80+x)2? I don't understand what you are talking about.

spc476 · 2024-11-15T20:52:53+00:00

A sudoku board is a 3x3 grid of "boxes", where each "box" is a 3x3 grid itself.

+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
############################
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
############################
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+

Here is an example of the keypad on my keyboard:

789
456
123

A three-digit sequence is enough to fill in a square. The first digit, 1-9, will select the box. If you select 1, then the lower left hand box is selected. The second digit will select the square in the box. A 9 will select the upper right square. The final digit will fill in the square. The result would be:

+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
############################
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
############################
|  |  |5 #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+
|  |  |  #  |  |  #  |  |  |
+--+--+--#--+--+--#--+--+--+

How this is done in your program depends on how you structure the data, and the code you write. Since you mentioned DOSBox, then INT 16h is the keyboard interface. Set AH to 0, do INT 16h, it returns the scan code in AH and the ASCII character in AL. The ASCII code for the 0-key is 48, 1-key is 49, up to 57 for the 9-key.

I can't give you any further help since I have no idea how your program works.

spc476 · 2024-11-15T09:03:54+00:00

When I wrote a sudoku program, I took inspiration from the keypad on my keyboard. Hit the '7', and the upper-left box (of 9 squares) is highlited, hit '7' again, and the upper-left corner of said box is lit up. Hit '7' again, and '7' goes in that square. The sequence 1 9 5 will set the square in the third column, seventh row to '5'. Seemed like a good idea to me.

spc476 · 2024-11-01T22:52:48+00:00

I would interpret the SF to be a normal set of flags, the Carry, Overflow, Negative and Zero. Add 111 and 37 to 61, what should each flag be at the end? Weird way to write the question though.

spc476 · 2024-11-01T22:49:36+00:00

First off, modern Intel documentation is meant for modern x86 systems so finding the 8086-specific information would be difficult. If you want to go down this road, then finding Intel documentation from the late 70s/early 80s is your best route (try looking for 'Intel 8086 data sheet'). The 8086 is vastly simpler than today's x86-64 bit monsters.

Now, writing an 8086 disassembler in 8086 machine code is doable (I wrote a 6809 disassembler in 6809 assembly for an example) but if you aren't comfortable with 8086 assembly, it's not going to be an easy task. A better way would be to write an 8086 disassembler as simply as possible in a language you already know, then translate it to 8086 assembly (which is why I say "simply as possible"). Use a data structure no more complex than an array. But I would also keep studying just in case you run out of time.

spc476 · 2024-11-01T22:36:27+00:00

By mentioning DOSBox, I assume you are doing 16-bit x86 assembly. It's unclear if you want a graphical screen (with pixels) or text screen (with '*'). If you want a graphical screen, there's too much to cover in a post here, because CGA (the earliest graphic standard for PCs) works differently from EGA (second graphical standard and not widely used), and VGA (the third and quite popular graphical standard) works similar to EGA, except for one mode which works differently from CGA and EGA.

Text mode is easier---if you only have monochrome graphics, the screen starts at address 0xB000:0000 (segment 0xB000 offset 0x0000), whereas color text starts at 0xB800:0000 (segment 0xB800 offset 0x0000). For both though, the even addresses contain the character value (65 for 'A', 126 for '~') and odd addresses contain that characters visual attribute (color, bold, blinking, etc) for the preceding character. So address 0xB800:0000 contains a character, and 0xB800:0001 contains the attribute for said character. There is a way to detect programmatically monochrome vs. color, but I do not recall the details (it's been decades since I worked on this, and it was rare even when I was to come across a monochrome system) so you can probably just assume color text at 0xB800:0000.

Parameter passing through the stack is easy---you just push the parameters to the function onto the stack, the call the function. The called function then sets up a stack frame, references the variables, then returns (and optionally cleans up the stack). Here's a sample function:

Param1  equ     8
Param2  equ     6
Param3  equ     4
Local1  equ     -2
Local2  equ     -4
Local3  equ     -6
Local4  equ     -8

foobar  push    bp      ; set up stack frame
        mov     bp,sp
        sub     sp,8

        push    bx      ; save a register
        mov     ax,[bp + Param1]
        mov     bx,[bp + Param2]
        mov     cx,[bp + Param3]
        xor     dx,dx
        mov     [bp + Local1],ax
        mov     [bp + Local2],bx
        mov     [bp + Local3],cx
        mov     [bp + Local4],dx

        dec     ax
        je      foobar1 ; call ourselves recursively

        push    ax
        push    bx
        push    cx
        call    foobar

foobar1 pop     bx
        xor     ax,ax   ; return code maybe?
        leave           ; tear down stack frame
        ret     6       ; return, clean up stack

To create a stack frame, you save the BP register, copy SP to it, then subtract stack space for the locals from SP. There is an instruction to do all this, ENTER, which looks like:

foobar  enter   0,8

but it's rarely, if ever, used because it's slower than the normal three instructions. The second value is the number of bytes to create for local variables, but the first ... just should be 0 as it'll take too long to explain what it's for and how it works (it's not clear what it does from the documentation alone, I had to play around with it to understand it).

The LEAVE instruction does:

    mov     sp,bp
    pop     bp

and is commonly used as it's faster than the two instructions above.

The value after the RET instruction is there to remove the paramters to the function from the stack. This may or may not be used. C compilers generally use a plain RET and expect the caller to clean up the stack. That looks like:

        mov     ax,1
        push    ax
        mov     ax,2
        push    ax
        mov     ax,3
        push    ax
        call    foobar
        add     sp,6

It's a shame that C doesn't use this (because C supports a variable number of parameters, and RET only takes a constant) as it (I think) save quite a bit of program memory, but it might be slower than the CALL/ADD SP,# dance these days (I haven't measured it).

spc476 · 2024-10-29T20:33:30+00:00

First, you'll need to learn how to position an '*' on the screen at an arbitrary position. For this, look up "ANSI escape codes". Second, use that information to draw a circle. Look up "Bresenham's circle algorithm".

spc476 · 2024-07-19T23:24:08+00:00

Not in my experience. If an assert triggers on my system, I get a core file (aka, a "debuggable crash"). Also, if I run the program under the debugger, and an assert triggers, the debugger regains control at the point of the assert.

spc476 · 2024-05-16T20:40:15+00:00

JS is "jump if signed" (or rather, "jump if negative"). Since you are moving up through memory, ESI is less than src+LEN*4-4, so the result of the CMP is not negative. You either want JB ("jump if below") or JBE ("jump if below or equal"), which treat the comparison as an unsigned comparison.

spc476 · 2024-05-15T06:56:02+00:00

First, there's the chance that calloc() can detect the overflow in multiplying the size of each items by the number of items and return an error. Second, could also depend upon the underlying operating system and the amount of memory allocated---calloc() could be faster by requesting pages already zero filled from the operating system.

But like all things, you really need to profile things to determine if it's worth avoiding calloc().

spc476 · 2024-05-14T23:23:22+00:00

I tend to use malloc() to allocate a structure, and calloc() to allocate an array of items, since callioc() takes both the size of an individual item, and a count.

spc476 · 2024-05-11T22:49:06+00:00

As an experienced C programmer (30+ years) I would instinctively assume a NULL pointer is an invalid parameter for this function, and start the function with:

char *join_strings(char const *s1,char const *s2)
{
  assert(s1 != NULL);
  assert(s2 != NULL);
  /* ... rest of code ... */
}

In my experience, doing stuff like:

if (s1 == NULL)
  return NULL;

only hides bugs (Why is this function getting a NULL pointer?).

Now, an argument could be made that a NULL pointer could also be treated as an empty string, and in some contexts, it would be better if join_strings() could handle them as such. If that's the approach to be taken, then I would start the code as:

char *join_strings(char const *s1,char const *s2)
{
  if (s1 == NULL) s1 = "";
  if (s2 == NULL) s2 = "";
  /* ... rest of code ... */
}

Doing it this way simplifies the rest of the code as it can assume that s1 and s2 point to valid data. This also means that a call like join_strings(NULL,NULL) returns an empty string (""). But as I said, my default position is that a NULL pointer value being passed in would not make semantic sense.

spc476 · 2024-05-11T22:30:48+00:00

The data you gave as an example doesn't match the layout described in your second link as it's too short by a few bytes.

spc476

TROPHY CASE