Blitzmax-NG for pentium 3 and below...

[Brucey]

Hallo 

If the latest compilers can compile for 386, then I don't see many issues being able to produce binaries for them.
Whether that is enough to get stuff working on older versions of Windows, I honestly cannot say.

XP would have the best chance of having something working. Earlier than that, I'd say much less likely - but you never know, I suppose... it may depend on what features you want to use.

I expect the GC to compile okay for older processors, but we might now be using some features on Windows that require a minimum version.

You could try setting an appropriate "arch" in bin/custom.bmk

setwin32ccopt arch -march=<something here>

where <something here> might be i386 (or pe386 - I'm not sure without googling it myself)

Also, saying "I don't mean to be rude" and then coming across as that, rather than just simply asking some questions about the state of NG on older versions of Windows, would probably elicit more friendly replies. Just saying.

[Yellownakji]

I attempted to set a custom arch.

-----------
C:/Users/YellowNakji/Desktop/blitzmax/Test/.bmx/main.bmx.gui.debug.win32.x86.c:1:0: error: CPU you selected does not support x86-64 instruction set
^
C:/Users/YellowNakji/Desktop/blitzmax/Test/.bmx/main.bmx.gui.debug.win32.x86.c:1:0: error: CPU you selected does not support x86-64 instruction set
Build Error: failed to compile (1) C:/Users/YellowNakji/Desktop/blitzmax/Test/.bmx/main.bmx.gui.debug.win32.x86.c
-----------

I also get this error when setting pentium4 as the target CPU but that isn't true because even if i don't set an arch, this app will run on my Pentium 4 machine that runs windows 2000.  It will also run on my celeron (not sure which version off the top of my head BUT, it's the one after pentium 3 and before pentium 4).

Have i missed something?

--

Also, i want to point out that i've switched to D3D9max2D.    Now that i've switched, i get "exception_violation" instead of an actual instruction error.   Getting there.

This error is also generated from the app, not from windows like the original one.

[Derron]

the EAV: is it catched in a debug build of your app?

in MaxIDE enable (compiler options) GDB information generation. Then build your app and run it via
BlitzMaxNG\MinGW32x86\bin\gdb.exe -r path\to\your\app.debug.exe
after it loaded, type "r[un]" and confirm with enter ... it should try to start your app and it should then segfault somewhere.

Now enter "bt" (backtrace) and it should output some stuff on where it exactly crashed - maybe this information could be of use for Brucey.


bye
Ron

[Yellownakji]

I can't run GDB; It's reported as invalid WIN32 application according to Windows2000.

I used "MINGW32/BIN/GDB.exe" and i am using NG 0.87.3.16.

My MaxIDE also does not have a GDB generation option;  Neither does BLIDE+15 or MaxIDEx.

[Derron]

MaxIDE (of NG)  - has it in a 3rd-level menu entry next to the architecture-submenu.


bye
Ron

[Yellownakji]

AH, i see it now. 

I ran GDB on my Windows10 rig,  here are the results: (see attachment)

--

I am not able to run GDB still on the target hardware but hopefully this information is useful for Brucey.   The lowest i can run my application on is Windows XP however, GDB won't work in XP either. 

Anyways...

[Derron]

And when you have this segfault, type in "bt" afterwards, so it tries to unwind what it has done before.


bye
Ron

[Yellownakji]

My mistake;  That part escaped me. 

Here:  Seems like another issue?

[Derron]

I got this issue these days too - within xp 64bit in a VM - did not happen before and Brucey did not reply to me questioning it.

So excuse for not being of help here - but next time the described approach might help to narrow down things.


bye
Ron

[Yellownakji]

I would test on a 32Bit machine but GDB isn't a WIN32 program, though it's in the MINGW32 folder and i am using X86 NG.......

I hope Brucey responds about this.

[Kippykip]

Gave it a little bit of a play myself, I made a very minimal program here:

Code Select Expand

Framework BRL.StandardIO
Print "loleksdee"
Delay 2000
Print "my nama jEFF"
Delay 2000
End


I was having different results with the compiler flags, using setwin32ccopt arch -mtune=nocona, I got this instead:


nocona being, 64-bit Pentium 4's. I thought it would work considering everything runs on my Pentium 4 machine just fine.

setwin32ccopt arch -mtune=pentium3m causes a different error rather than just skipping over it, "CPU you selected does not support x86-64 instruction set"


Couldn't find much information for other flags, I found -mtune did the same errors.
I did stumble on a similar error on the mojolabs.nz archives, something about using "setccopt optimization -O2" but I found it didn't change anything.

Yellownakji did find out by using DX9's Max2D (or simply not using Max2D at all), you can get a different error which is the generic "EXCEPTION_ACCESS_VIOLATION".
So maybe something is partially working on a P3?

Although I'm no expert at all when it comes to GCC or MinGW, hence why I use BlitzMax to code in the first place

[Yellownakji]

There's also these flags (see attach 00..)...

But they didn't help either.   Actually, setting an arch won't compile at all due to the CPU not supporting like in Kippy's screenshots.  I got the same results.

If we use -m32 with the arch, IT WILL compile but still does not allow for running on a Pentium 3.   Actually, it probably only compiled because the -m32 flag ignored the arch completely.  My guess. (see attach 01..)...

[Brucey]

Hi. How about this file?

[Yellownakji]

That actually worked.   

All of our attempts just return the generic "access_violation" exception.

[Brucey]

That was made with a clean copy of https://github.com/bmx-ng/bmx-ng/releases/tag/v0.93.3.21.win32.x86

and a line in custom.bmk :

Code Select Expand

setwin32ccopt arch -march=i486

Then I just did a console release build of your example source.

If you ever get errors which mention x86_64 then you have something trying to build/link for x64 and something else trying to build/link for x86.

I recommend developing with the latest mingw-w64, which has separate bundles for x86 and x64 development. bmk will choose the appropriate mingw based on what you are trying to build - there are currently 4 places bmk looks at to determine the version of mingw you are using...

• MinGW32x86 or MinGW32x64 sub directory of BlitzMax- for 32-bit and 64-bit specific MinGW distros.
• MinGW32 sub directory of BlitzMax - for combined 32/64 bit distros - or 32-bit or 64-bit specific distro, but expect to have problems if you try to build x86 with a 64-bit only distro.
• MINGW on the path. This is the legacy way of using MinGW with BlitzMax.