Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

FPC 2.6.4 released! (Announce)

posted by nickysn(R), 06.04.2014, 00:26

> > > there is a bug (or unimplemented feature?) that makes every program
> > > say "Nil pointer assignment" on exit (even something as banal as
> > > "Hello, world!").
> >
> > That sounds like you got either the units or the startup code for
> different
> > memory models mixed up.
> AFAIK, the ppcross8086.exe is the same for both Tiny, Small. The only
> difference is the compiled units, etc. Yes, I just confirmed it, latest
> snapshot .EXE is same size, same CRC32 in both .ZIPs.
> > If the correct startup code for tiny (prt0t.o) is
> > linked, you should never get a "Nil pointer assignment" error, because
> nil
> > pointer checking can only work in the small and medium memory models
> (which
> > have a separate data segment, so that we can initialize the first few
> bytes
> > at DS:0000 with a preset pattern and then check it at the end of program
> > execution), so it is simply ifdef'd out in the startup code for tiny.
> I'm atop Win64 right now and just tested a simple hello world with latest
> Tiny snapshot.
> ppcross8086 -XX hello -oa.exe
> ppcross8086 -XX -WmTiny hello -ob.exe
> Here's what DOSBox says:
> C:\TMP\BLA>a
> Hello, world!
> Nil pointer assignment
> C:\TMP\BLA>b
> Hello, world!

Strange, it doesn't happen on my machine. I'm using linux (x86_64), openwatcom 1.9, nasm 2.10.07 and dosbox and it works fine. How did you build the snapshot?

> FYI, both .EXEs contain the string "Nil pointer assignment", so it's not
> totally ifdef'd out.

The string exists in both, but it's only printed after a function call to the startup code, which checks the byte pattern in the beginning in the of the data segment. See the FPC_CHECK_NULLAREA label in:

> But beyond that, I don't know. Maybe it's a mistake to
> assume the Tiny build always builds tiny. But I just blindly assumed it
> wasn't necessary to tell it. Though of course the compiler .EXE probably
> doesn't know any better if it's the same for each. Maybe there is no
> default memory model. Dunno if that's a bug or (more likely) user error.
> In short, we should probably always explicitly specify a memory model when
> compiling. Maybe it should error out if none is specified by default.

The default memory model is 'small'. There are also some flags in the .ppu header which indicates for which memory model the given unit was built. But it doesn't matter for small and tiny, because the .ppus are compatible and these flags are identical in those two memory models. The only difference is the startup code - prt0s.o is for small, while prt0t.o is for tiny. The appropriate one is chosen by the compiler and put in the linker script according to the -Wm option.


Complete thread:

Back to the forum
Board view  Mix view
15297 Postings in 1378 Threads, 254 registered users, 10 users online (0 registered, 10 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum