Help from a C expert requested

[Hated Moron]

I have encountered an issue in one of the BBCSDL source files (bbexec.c) but I'm unsure of the cause. This code normally runs fine (on multiple platforms and CPU types):

Code: Select all

esi = oldesi - 1;
esi = argue((signed char *)accs - 1, (void *)(esp + 2), 1);

where esi is declared as a global register variable thus:

Code: Select all

register signed char *esi asm ("esi");	// Program pointer

However when compiled with GCC 12.2.0 in Windows (targetting 32-bit i386 code) it does not work. The symptom would suggest that the global register variable esi (which is used internally by the function argue) is not being updated correctly by the first statement. It's almost as if the compiler doesn't realise it's a global variable which might be used in a called function.

I can fix the issue by introducing a dummy volatile variable (in an attempt to create a sequence point) thus:

Code: Select all

volatile int seq;
esi = oldesi - 1;
for (seq=0; seq<1; seq++);
esi = argue((signed char *)accs - 1, (void *)(esp + 2), 1);

although replacing the for statement with seq++; is not effective.

Is this a compiler bug, or am I doing something which triggers Undefined Behaviour? If the latter, what am I doing wrong? If the former, what's the best workaround?

And before somebody says I shouldn't be using global register variables, I would draw attention to this comment in the GCC docs: "For example [these] may be useful in programs such as programming language interpreters that have a couple of global variables that are accessed very often". This is exactly the situation in BBC BASIC!

[hellomike]

Richard,

You mean that you need an expert even better than someone who wrote an entire interpreter in thousands of source code lines in C.
I would assume you get better (i.e. any?) help in a dedicated GCC forum.

Regards,

Mike

[Hated Moron]

You mean that you need an expert even better than someone who wrote an entire interpreter in thousands of source code lines in C.

No, somebody with that qualification would probably be able to help. Indeed, I have already asked the only person I know who comes close to that description: Michael McConnell who is the author of Matrix Brandy BASIC.

I would emphasise that I am not myself a C programmer, indeed I have never written an entire C program from scratch in my life. What I have done successfully in C are two things:

• Make small modifications to an existing C program written by somebody else.
• Semi-mechanically translate the assembly-language source code of BBC BASIC for Windows into the C source code of BBC BASIC for SDL 2.0.

Neither of those 'skills' (if you call them that) have any bearing on the issue at hand, because they require only the most primitive knowledge of C - just enough to know roughly the language syntax (such as every statement ending with a semicolon). They don't require any understanding at all of the 'higher level' rules of the language which, if not followed strictly, may result in Undefined Behaviour.

If you are suggesting that, at my age and with ever-deteriorating Cognitive Decline, I should consider learning enough about C to answer the question myself, that is not helpful. Alternatively, if you are suggesting that it is inappropriate for me to ask that kind of question here I completely disagree, because I know for sure that there are members of this forum (or the discussion group to which posts are automatically copied) who know far more about C than I do.

[Hated Moron]

• Semi-mechanically translate the assembly-language source code of BBC BASIC for Windows into the C source code of BBC BASIC for SDL 2.0.

I am sure I have previously described how I - with negligible knowledge of C - managed to translate the IA-32 assembly-language source code of BBC BASIC for Windows into the C the source code of BBC BASIC for SDL 2.0; but I can't find it on a quick search.

The first step was to write a BBC BASIC program which could automatically translate those assembly language statements with direct C equivalents. So for example mov ebx,ecx would be translated to ebx = ecx;, inc edx would be translated to edx++; etc.

A quick glance at the BBCSDL C code will reveal the large number of variable names that correspond directly with i386 register names! Here's an example (slightly simplified) taken from the code for DIM:

Code: Select all

	eax = *(esp + i) ;
	*edi = eax ;
	edi += 4 ;
	ebx *= eax ;

The next step was to automatically top-and-tail subroutines with C-style preambles and postambles. This was made much easier than it might have been because of my habit of adding reasonably-standardised comments to the assembler code, listing the subroutine's inputs, outputs and destroyed registers.

This was largely the limit of the automatic translation, and the residual manual translation of statements without a direct equivalent did take about a year. But the key point is that none of it required anything more than a primitive knowledge of C. Anybody could have done it.

[hellomike]

I certainly was not suggesting any of those. Not sure why you would even consider that I would. Never mind.

The Semi-mechanically translate in itself is fantastic and you are wrong about that anybody could have done that. I couldn't for starters.

I hope you find the apparent GCC 12.2.0 compiler anomaly.

Regards,

Mike

[STOS]

Allthough not a Windows user myself, well not since XP and not able to test myself.

It might be helpul for others to just clarify that...

However when compiled with GCC 12.2.0 in Windows (targetting 32-bit i386 code) it does not work.

Can we assume that it did work in GCC version < 12.2.0?
and
You have tried compiling using GCC 12.3?

[Hated Moron]

Can we assume that it did work in GCC version < 12.2.0?

I can't say on which version(s) it works and on which it doesn't because (like most people, I would expect) I don't update my tools every time a new version of GCC is released. Indeed I've probably used only three different versions or so over the last 20 years!

You have tried compiling using GCC 12.3?

I didn't know there was a 12.3, and I can't download it until I'm back at home because the internet speed here on the ship is quite low.

[Hated Moron]

you are wrong about that anybody could have done that. I couldn't for starters.

Any competent i386 Assembly Language programmer I meant. Obviously to do the translation you need to have a good idea of what the original code did, which means at least being familiar with the CPU's instruction set and registers. But with that knowledge, which is common amongst BB4W programmers because of the inline assembler, translation to C requires a minimal understanding of that language.

And in fact many BB4W programmers know more about C than perhaps they think they do, because of the SYS statement. To use SYS to call a Windows API function you firstly need to look up that function, typically at MSDN (as was), to find out what parameters it takes and what value, if any, it returns. That specification invariably uses C syntax, and if there's an example of how the function is used that code will be C too!

So, one way or another, many BB4W programmers will have sufficient knowledge to do the kind of semi-automated translation I did. I have to hope so, anyway, because if 'my' BBC BASICs are to survive me (and we're not talking about very long) there will need to be people who can maintain the C code at GitHub and they are more likely to know BBC BASIC than C!

[hellomike]

Indeed in the MSDN documentation, I check the IN and OUT type and values and C code like:

Code: Select all

HFONT CreateFontA(
  [in] int    cHeight,
  [in] int    cWidth,
  [in] int    cEscapement,
  [in] int    cOrientation,
  [in] int    cWeight,
  [in] DWORD  bItalic,
  [in] DWORD  bUnderline,
  [in] DWORD  bStrikeOut,
  [in] DWORD  iCharSet,
  [in] DWORD  iOutPrecision,
  [in] DWORD  iClipPrecision,
  [in] DWORD  iQuality,
  [in] DWORD  iPitchAndFamily,
  [in] LPCSTR pszFaceName
);

is rather straightforward and does help.

However with code like the following

Code: Select all

	while ((MaximumRAM > DEFAULT_RAM) &&
			((void*)-1 == (userRAM = mmap ((void *)0x10000000, MaximumRAM, 
						PROT_EXEC | PROT_READ | PROT_WRITE, 
						MAP_PRIVATE | MAP_ANON, -1, 0))) &&
			((void*)-1 == (userRAM = mmap ((void *)0x10000000, MaximumRAM, 
						PROT_READ | PROT_WRITE, 
						MAP_PRIVATE | MAP_ANON, -1, 0))))

one has to know a lot already about the perks/syntax of the C programming language. Regardless if it is written from scratch or semi-automated translated. No person in the world only having a minimal understanding can do this.

If you disagree then we simply have a completely different view of what is considered minimal understanding in regards to a programming language.

Mike

[Hated Moron]

However with code like the following
...
one has to know a lot already about the perks/syntax of the C programming language.

You are choosing as your example a piece of code which was not translated from assembly language, so I don't think it's a fair illustration. It's not even part of the BBC BASIC interpreter, indeed it's not code which is in the Windows edition of BBC BASIC for SDL 2.0 at all (it's Linux code)!

Regardless if it is written from scratch or semi-automated translated. No person in the world only having a minimal understanding can do this.

So how do you think I managed to produce that code? Although I can't actually remember now, it's highly likely that I Googled for something like 'how to allocate memory in Linux' which took me to one of the sites (e.g. StackOverflow) where you can find huge quantities of code examples to do almost anything.

That's the 'usual' way I write C code which needs to be written afresh rather than translated from the BB4W equivalent (obviously there's nothing Linux-related in BB4W).

If you disagree then we simply have a completely different view of what is considered minimal understanding in regards to a programming language.

I do disagree. With the resources available on the internet, allowing you to find C code to do pretty much anything you can imagine, the level of understanding required to build a working app by combining those building blocks into a self-contained program is minimal, especially if you already know another programming language like BASIC.

You can of course choose to believe that I am lying, but the facts of the matter are that I have never actively learned to program in C nor have I ever written a C program from scratch. The degree of knowledge of that language I have acquired has been purely by exposure to code examples at MSDN or elsewhere and by searching the internet.

Where I may have an advantage over some other people is that I don't automatically assume that I won't be able to do something, which I'm afraid is a common failing of BBC BASIC programmers. The number of times I have seen, here or at other BBC BASIC forums, somebody say "I wouldn't know where to start" or "it's gobbledegook to me" or "there's no point me even trying because I won't understand it" is depressing.

Knowing BBC BASIC gives you more than enough understanding of how computer programs are structured to be able to make sense of code written in any other traditional language. Once you move into, say, the Object Oriented Programming paradigm then I can understand how there can be roadblocks, but C is so similar to BASIC in its fundamentals the problem is only a psychological one.