smaller c preprocessor

[muta...@gmail.com]

Hi Alexey.

I had another crack at using Smaller C to build
PDOS, and after rebuilding (with Borland C) with
larger defines, I was able to get past all the
constraints. There was just one place that took
quite a while to figure out. I'm not used to
debugging at that level.

If you look here:

C:\devel\pdos\src>smlrpp -o temp.e temp.c

C:\devel\pdos\src>type temp.c
fatfile->lastBytes = (unsigned int)
(fatfile->fileSize
% ((unsigned long)fat->sectors_per_cluster
* (unsigned long)fat->sector_size));

C:\devel\pdos\src>type temp.e
#line 1 "temp.c"
fatfile->lastBytes = (unsigned int)
(fatfile->fileSize
((unsigned long)fat->sectors_per_cluster
* (unsigned long)fat->sector_size));


You can see the "%" has disappeared. All the
preprocessor needed to do was copy input to
output, instead of mangling it. I was previously
compiling with Cygwin gcc (just by running
"make"), but I switched to Borland C to see if
it was a compiler issue.

bcc32 -DSTAND_ALONE -DSTD_MACROS=0 -DSTD_ASSERT=0 -DUCPP_CONFIG cpp.c mem.c nhash.c lexer.c assert.c macro.c eval.c arith.c

But it had the same issue. I took a look at lexer.c
and it was way too complicated for me to understand.

But I actually have another preprocessor-only program,
which is public domain, so I switched to that. That
showed an unrelated problem with the PD version, so I
have asked the author to see if he can fix that.

I used this for Smaller C BTW:

bcc32 -DMAX_IDENT_TABLE_LEN=20000 -DSYNTAX_STACK_MAX=10000 -DSTACK_SIZE=500 smlrc.c

Anyway, with all that done, the only thing that
Smaller C can't cope with is some floating point
stuff in PDPCLIB.

One of them is this:
smlrc -huge -I . math.e math.s
Error in "math.c" (720:18)
Compound assignment not supported with floats

I simplified it to:

__PDPCLIB_API__ double modf(double value, double *iptr)

value -= 5.0;

If I change that to:

value = value - 5.0;

it is accepted. Is the original syntax difficult to support?

Thanks. Paul.

[Alexei A. Frounze]

On Friday, April 2, 2021 at 10:52:01 PM UTC-7, muta...@gmail.com wrote:
> Anyway, with all that done, the only thing that
> Smaller C can't cope with is some floating point
> stuff in PDPCLIB.
>
> One of them is this:
> smlrc -huge -I . math.e math.s
> Error in "math.c" (720:18)
> Compound assignment not supported with floats
>
> I simplified it to:
>
> __PDPCLIB_API__ double modf(double value, double *iptr)
>
> value -= 5.0;
>
> If I change that to:
>
> value = value - 5.0;
>
> it is accepted. Is the original syntax difficult to support?

It's not the syntax itself, but what it entails.

a += b;
is equivalent to
a = a + b;

Which generally expands into:
a = (type_of_a)((common_type_between_a_and_b)a +
(common_type_between_a_and_b)b);

So, to support this operator with floats you need to break down
+= into separate = and + and be able to insert up to 2 casts in 3 places
in that.

Smaller C represents expressions internally not as trees but in
reverse Polish notation and that, unlike trees, is often inconvenient
to manipulate with.
But if I restrict += to integers and pointers, it's much easier to do.
So, I didn't implement += and such for floating types.

You did just the right (and trivial) workaround.

Alex

[muta...@gmail.com]

On Saturday, April 3, 2021 at 5:41:57 PM UTC+11, Alexei A. Frounze wrote:

> Smaller C represents expressions internally not as trees but in
> reverse Polish notation and that, unlike trees, is often inconvenient
> to manipulate with.
> But if I restrict += to integers and pointers, it's much easier to do.
> So, I didn't implement += and such for floating types.

Ok, an interesting real-world constraint on the C language.

I have gone ahead and made all those changes to PDPCLIB,
so now there is nothing at all that Smaller C doesn't like.

Next step is to get the limitation on pdcc lifted and then
flesh out the startup/support assembler code for Smaller C
executables. Which needs to be nasm it seems, but it's
probably about time I switched to nasm as I don't have
any freely-available tool otherwise, now that I know there
are limitations on wasm. Not sure how that will cope with
my mixed-mode assembly.

BFN. Paul.

[muta...@gmail.com]

On Saturday, April 3, 2021 at 4:52:01 PM UTC+11, muta...@gmail.com wrote:

> I had another crack at using Smaller C to build
> PDOS, and after rebuilding (with Borland C) with
> larger defines, I was able to get past all the
> constraints.

Wow. You managed to write a good-enough C
compiler in 14,000 lines of code.

And the executable is only 93k when using
msvcrt.dll. This is a miracle of engineering.

I don't know what the run-time memory
requirements, but this may run under MSDOS.

That opens up whole new possibilities. I have
previously been running under the assumption
that you need 23 MB to run a C compiler, and
they require 400,000 lines of code. I know
Turbo C etc ran under MSDOS, but I believe
they were kludged (with overlays or whatever)
to work, which is not something I am interested
in doing.

BFN. Paul.

[muta...@gmail.com]

I'm trying to figure out what should have been done
at MSDOS 1.0 rollout.

Some sort of warning that the 8086 was designed to
allow 8080 programs to be loaded at convenient
boundaries instead of needing to be located at a
64k boundary.

And if you code your new applications to reside
within 64k, that's fine too.

But if you wish to exceed 64k for an application, we
don't want you mucking around with cs and ds in
the long term. We will bring out a new 32-bit
processor instead. It will still allow addressing of
1 MB, still fitting into the segmentation model, but
it will use 32-bit registers to do that.

It's only 14,000 line of code to do that if you know
the right people.

So just wait a few years, then be ready to recompile
all your software.

And remember, only do this if you really need to
exceed 64k.

It's unclear to me whether the small memory model
would have been OK too, so allowing 64k of code
and 64k of data. So long as the executable format
is sound, MSDOS could have placed this into
memory nicely without the application being aware
of cs/ds.

Actually, I think we want large memory model, to
give a future OS the ability to correct all the
segments. Nope, that's not going to work either.

What advice do you give programmers while waiting
for the 80386?

I think we need magical huge pointers on the 8086
while waiting for an 80386 that will do the same thing.

BFN. Paul.

[muta...@gmail.com]

On Sunday, April 4, 2021 at 6:00:59 PM UTC+10, muta...@gmail.com wrote:

> So just wait a few years, then be ready to recompile
> all your software.

> What advice do you give programmers while waiting
> for the 80386?
>
> I think we need magical huge pointers on the 8086
> while waiting for an 80386 that will do the same thing.

And then be ready to recompile the same software yet
again, as we make the segment shift 16 bits, to give
effectively flat 32-bit pointers?

And MSDOS 1.0 provides APIs to future-proof the
software?

BFN. Paul.

[muta...@gmail.com]

On Saturday, April 3, 2021 at 6:42:06 PM UTC+11, muta...@gmail.com wrote:

> Next step is to get the limitation on pdcc lifted and then

This has been done, but it has another limitation
if I choose to use it on PDPCLIB. But using it just
for PDOS means I have a solution for everything.
ie Smaller C compiles all of my important code.

> flesh out the startup/support assembler code for Smaller C
> executables. Which needs to be nasm it seems, but it's
> probably about time I switched to nasm as I don't have
> any freely-available tool otherwise, now that I know there
> are limitations on wasm. Not sure how that will cope with
> my mixed-mode assembly.

Actually, what I think I want is a wasm-compatible
8086 assembler that generates the ELF object code
that Smaller C requires. The assembler only needs
to be good enough to assemble the startup/support
code required to satisfy Smaller C. nasm itself can
be treated as an extension of Smaller C.

BFN. Paul.

[muta...@gmail.com]

What changes would be required to make Smaller C
support 64-bit pointers, but no "long long" and just
32-bit longs?

Or is there some technical barrier to that?

I don't care if the extra x64 registers are dedicated
to 64-bit pointers and all normal 32-bit code is
restricted to normal 32-bit registers. I also don't
care if a 64-bit register is zeroed every time it
ceases to be used as a pointer, ready to be used
by 32-bit arithmetic instructions.

Thanks. Paul.

[Alexei A. Frounze]

On Sunday, April 4, 2021 at 7:52:21 AM UTC-7, muta...@gmail.com wrote:
> What changes would be required to make Smaller C
> support 64-bit pointers, but no "long long" and just
> 32-bit longs?

Lots of changes. Every numeric and pointer type is int-sized or smaller.
It's almost as if you had just one type for everything.

> Or is there some technical barrier to that?

Just the limitations of the original design. Take a look at any classical
Small C implementation (e.g. by Hendrix, Cain, etc). It's the most common
limitation that there aren't any numeric/pointer sizes twice the size of int.

Alex

[muta...@gmail.com]

On Monday, April 5, 2021 at 2:50:56 AM UTC+10, Alexei A. Frounze wrote:

> > What changes would be required to make Smaller C
> > support 64-bit pointers, but no "long long" and just
> > 32-bit longs?

> Lots of changes. Every numeric and pointer type is int-sized or smaller.
> It's almost as if you had just one type for everything.

> > Or is there some technical barrier to that?

> Just the limitations of the original design. Take a look at any classical
> Small C implementation (e.g. by Hendrix, Cain, etc). It's the most common
> limitation that there aren't any numeric/pointer sizes twice the size of int.

Ok, if the problem is that they need int = long = ptr then
how much change is required to make 64-bit int/long/ptr?

I don't care if just the normal eax/ebx etc are changed to
rax/rbx etc, no use of additional registers.

Thanks. Paul.

[Alexei A. Frounze]

On Sunday, April 4, 2021 at 2:15:18 PM UTC-7, muta...@gmail.com wrote:
> Ok, if the problem is that they need int = long = ptr then
> how much change is required to make 64-bit int/long/ptr?

Before we get to other things, there's one big question as to how to
fill the type gap between 8 and 64 bits.
char/byte = 8 bits
short = 16 bits
int/long/ptr = 64 bits

Do we not have any standard C type for 32-bit ints?
Or do we make short equal to 32 bits and drop 16-bit ints instead?
Or introduce a non-standard type for one of those two sizes?
Or what?

Nontraditional type sizes are problematic in terms of compatibility
and porting. Like 16-bit chars or 96-bit all other ints.

The other things being:
- new, 64-bit file formats to support (PE, ELF, Mach-O)
- new, 64-bit ABIs to support
- bootstrapping (I don't have an x86 compiler with plain ints being 64-bit)
- possibly some issues w.r.t. addressing in 64-bit assembly code
(there are different modes, AFAIR; I never used NASM/YASM/FASM
for 64-bit code)

Alex

[muta...@gmail.com]

On Monday, April 5, 2021 at 7:34:51 AM UTC+10, Alexei A. Frounze wrote:

> > Ok, if the problem is that they need int = long = ptr then
> > how much change is required to make 64-bit int/long/ptr?

> Before we get to other things, there's one big question as to how to
> fill the type gap between 8 and 64 bits.
> char/byte = 8 bits
> short = 16 bits
> int/long/ptr = 64 bits
>
> Do we not have any standard C type for 32-bit ints?
> Or do we make short equal to 32 bits and drop 16-bit ints instead?

I'm thinking about switching from real mode to long
mode, so 16-bit shorts would be good to keep for a
return to real mode to do a BIOS interrupt.

So yes, 32-bit ints would not be supported, to take
the burden off the compiler (and onto me!).

> Or introduce a non-standard type for one of those two sizes?
> Or what?

No. Just the simple change above.

> Nontraditional type sizes are problematic in terms of compatibility
> and porting. Like 16-bit chars or 96-bit all other ints.

It is up to the C programmer to write code that will
work in the above scenario. If you can produce the
C compiler that does any of the above things, the
C programmer does the rest.

> The other things being:
> - new, 64-bit file formats to support (PE, ELF, Mach-O)
> - new, 64-bit ABIs to support

Don't change any of that. Let the format naturally
change with the new size types. Not your problem.

> - bootstrapping (I don't have an x86 compiler with plain ints being 64-bit)

Can you explain why that is required? Don't you just
need to change eax references to rax in the output
nasm? ie this is all text.

The Smaller C code itself doesn't use constant values
greater than 4 GiB, so is there a problem?

Or are you referring to the linker? Let me think about
that more to try to figure out what the issue is.

> - possibly some issues w.r.t. addressing in 64-bit assembly code
> (there are different modes, AFAIR; I never used NASM/YASM/FASM
> for 64-bit code)

Ok, I've never really been involved in 64-bit code either.
But I'm thinking of branching out with Smaller C.

BFN. Paul.

[Alexei A. Frounze]

On Sunday, April 4, 2021 at 5:09:32 PM UTC-7, muta...@gmail.com wrote:
> On Monday, April 5, 2021 at 7:34:51 AM UTC+10, Alexei A. Frounze wrote:

...

> > The other things being:
> > - new, 64-bit file formats to support (PE, ELF, Mach-O)
> > - new, 64-bit ABIs to support
> Don't change any of that. Let the format naturally
> change with the new size types. Not your problem.

Windows, Linux and MacOS will say malformed executables
aren't their problem either. :)

> > - bootstrapping (I don't have an x86 compiler with plain ints being 64-bit)
> Can you explain why that is required? Don't you just
> need to change eax references to rax in the output
> nasm? ie this is all text.
>
> The Smaller C code itself doesn't use constant values
> greater than 4 GiB, so is there a problem?

You're ignoring lots of things, which are needed for a conformant
and usable compiler. Among them are:
- compile-time constant expression evaluation
- sizes of variables holding pointers
- integer type capable of converting to a pointer and back
- stack alignment (and the rest of the ABIs)

> Or are you referring to the linker?

That too, implied and involved in the executable format support.

> Let me think about
> that more to try to figure out what the issue is.

Not to be rude, but you should probably write a C compiler yourself
to be able to see more than and beyond "change eax references to rax".
:)

Alex

[muta...@gmail.com]

On Monday, April 5, 2021 at 11:32:51 AM UTC+10, Alexei A. Frounze wrote:

> > > The other things being:
> > > - new, 64-bit file formats to support (PE, ELF, Mach-O)
> > > - new, 64-bit ABIs to support

> > Don't change any of that. Let the format naturally
> > change with the new size types. Not your problem.

> Windows, Linux and MacOS will say malformed executables
> aren't their problem either. :)

PDOS/x64 won't though.

From smlrc.md:
* It may be useful as a simple and small (cross-) compiler for DOS,
RetroBSD or other OSes, including hobby OSes

> > > - bootstrapping (I don't have an x86 compiler with plain ints being 64-bit)
> > Can you explain why that is required? Don't you just
> > need to change eax references to rax in the output
> > nasm? ie this is all text.
> >
> > The Smaller C code itself doesn't use constant values
> > greater than 4 GiB, so is there a problem?

> You're ignoring lots of things, which are needed for a conformant
> and usable compiler. Among them are:
> - compile-time constant expression evaluation
> - sizes of variables holding pointers
> - integer type capable of converting to a pointer and back
> - stack alignment (and the rest of the ABIs)

Ok, let me see if someone else can provide a compiler
with 64-bit ints to use in the bootstrap process.

> Not to be rude, but you should probably write a C compiler yourself
> to be able to see more than and beyond "change eax references to rax".
> :)

There are some things beyond my capability. Like writing
a rock song as per Rolling Stones etc. Even if given 1000
years to do it.

I suspect that language parsing is one of those things.
Either way, my priority is still to *use* a compiler, not
*write* one.

So if the target is PDOS/x64 which has an executable
format not yet defined (ie whatever smlrl produces
with no change will be it), and I can find a bootstrap
compiler with 64-bit ints (incidentally, "int" is supposed
to be the natural register size of the target platform,
so 64-bit is more accurate), and nasm supports
64-bit registers (I just checked, it does), then how much
work is required to provide a -seg64 option in smlrc?

Thanks. Paul.

[muta...@gmail.com]

Is it technically possible to write the startup/support
assembler code for Smaller C -huge in wasm (which
I think produces coff) instead of nasm/elf?

ie can you convert from coff object code into elf
object code?

Or is it necessary to have a wasm-compatible
assembler that produces elf?

Thanks. Paul.

[Rod Pemberton]

On Mon, 5 Apr 2021 11:54:36 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:

> wasm (which I think produces coff) instead of nasm/elf?

Sigh, dude, that's /really/ an RTFM ... :-(


DJGPP produces a COFF variant, i.e., DJGPP/COFF instead of PE/COFF.
http://www.delorie.com/djgpp/doc/coff/

Making HX PE binaries with DJGPP by Japheth
https://www.japheth.de/HX/djgpp.html


OpenWatcom produces a bunch of stuff. Your choice. From the linker
guide (LGUIDE.TXT) in the binw directory for OpenWatcom version 1.30,

"The Open Watcom Linker is a linkage editor (linker) that takes object
and library files as input and produces executable files as output. The
following object module and library formats are supported by the Open
Watcom Linker.

- The standard Intel Object Module Format (OMF).
- Microsoft's extensions to the standard Intel OMF.
- Phar Lap's Easy OMF-386 object module format for linking 386
applications.
- The COFF object module format.
- The ELF object module format.
- The OMF library format.
- The AR (Microsoft compatible) object library format.

The Open Watcom Linker is capable of producing a number of executable
file formats. The following lists these executable file formats.

- DOS executable files
- ELF executable files
- executable files that run under FlashTek's DOS extender
- executable files that run under Phar Lap's 386|DOS-Extender
- executable files that run under Tenberry Software's DOS/4G and
DOS/4GW DOS extenders
- NetWare Loadable Modules (NLMs) that run under Novell's NetWare
operating system
- OS/2 executable files including Dynamic Link Libraries
- QNX executable files
- 16-bit Windows (Win16) executable files including Dynamic Link
Libraries
- 32-bit Windows (Win32) executable files including Dynamic Link
Libraries"


I'm not sure what information is included in the documentation for more
recent versions of OpenWatcom. Apparently, they're officially on
version 1.90 (5/25/2010), i.e., stalled 2010.
http://openwatcom.org/

Wikipedia says they're working on a new OpenWatcom version on Github.
Apparently, it includes better DOS support for LFNs and 64-bit. A
decade ago they were discussing OpenWatcom for Linux on their newsgroup.
I don't know what happened with that goal or idea, which would be
an excellent option.
http://open-watcom.github.io/

--
Facebook's security is like a water bucket that's full of bullet holes.

[muta...@gmail.com]

On Tuesday, April 6, 2021 at 8:12:37 AM UTC+10, Rod Pemberton wrote:

> > wasm (which I think produces coff) instead of nasm/elf?

> OpenWatcom produces a bunch of stuff. Your choice. From the linker
> guide (LGUIDE.TXT) in the binw directory for OpenWatcom version 1.30,

It is the assembler I asked about. smlrl requires ELF
object code.

So now I'm a bit stuck as I would need to develop in
nasm when I would rather be wasm/masm-compatible
for eventual replacement with commercial tools.

The idea is that someone can take PDOS and convert
it into a commercial product, maintained with
Microsoft tools rather than stuff downloaded from
the internet.

BFN. Paul.

[Alexei A. Frounze]

On Sunday, April 4, 2021 at 7:37:47 PM UTC-7, muta...@gmail.com wrote:
> On Monday, April 5, 2021 at 11:32:51 AM UTC+10, Alexei A. Frounze wrote:
> > Not to be rude, but you should probably write a C compiler yourself
> > to be able to see more than and beyond "change eax references to rax".
> > :)
> There are some things beyond my capability. Like writing
> a rock song as per Rolling Stones etc. Even if given 1000
> years to do it.
>
> I suspect that language parsing is one of those things.
> Either way, my priority is still to *use* a compiler, not
> *write* one.

Writing a compiler would likely force you to better learn and
understand the language. If you're determined, you can dissect
the language standard without writing a compiler, but many
*users*, way too many, forgo doing this unless they have a
task requiring implementing something very very portable
and durable.

Parsing itself isn't too hard, unless you want to masochistically
explore the myriads of largely useless grammars and their
intricacies.
Optimizations are harder than parsing.

Alex

[Alexei A. Frounze]

On Monday, April 5, 2021 at 11:54:37 AM UTC-7, muta...@gmail.com wrote:
> Is it technically possible to write the startup/support
> assembler code for Smaller C -huge in wasm (which
> I think produces coff) instead of nasm/elf?
>
> ie can you convert from coff object code into elf
> object code?

objconv and objcopy might work. Not sure I ever used either.

> Or is it necessary to have a wasm-compatible
> assembler that produces elf?

Possibly JWASM would work. Never used it.

But I see no point in this. NASM and YASM work out of the box
with Smaller C.

Alex

[muta...@gmail.com]

On Tuesday, April 6, 2021 at 4:10:29 PM UTC+10, Alexei A. Frounze wrote:

> > ie can you convert from coff object code into elf
> > object code?

> objconv and objcopy might work. Not sure I ever used either.

> > Or is it necessary to have a wasm-compatible
> > assembler that produces elf?
> Possibly JWASM would work. Never used it.

Thanks for both great pointers! I have both of those
available, I'll see if I can switch back to masm syntax.

> But I see no point in this. NASM and YASM work out of the box
> with Smaller C.

I see no reason for nasm to go to all that effort to create
an assembler, and not bother to support the elephant
in the room - Microsoft's masm. Just some minimal
subset would be fine, so that I can write code that works
under both nasm and masm. And wasm too.

Anyway, I have a new question. Smaller C (as documented)
doesn't support bitfields. Is that because it is too difficult
to parse using recursive descent? Note that I would be
happy if unsigned int x : 1; was translated into simply
unsigned int x. I don't care about saving space, I'm only
interested in getting a compile to go through.

Thanks. Paul.

[Alexei A. Frounze]

On Tuesday, April 6, 2021 at 12:12:04 AM UTC-7, muta...@gmail.com wrote:
> Anyway, I have a new question. Smaller C (as documented)
> doesn't support bitfields. Is that because it is too difficult
> to parse using recursive descent? Note that I would be
> happy if unsigned int x : 1; was translated into simply
> unsigned int x. I don't care about saving space, I'm only
> interested in getting a compile to go through.

Besides additional parsing work (which isn't a big deal by itself),
it would require more complex internal declaration representation
and, most importantly, expression manipulation.
Like I said earlier, supporting += and such is complicated
precisely because of manipulating the expression's
Reverse Polish Notation.
Bitfields (and C99 bools for that matter) need a similar kind
of manipulation. Without bitfields, every . and -> simply accesses
1, 2 or 4 bytes at (struct/union pointer + field offset), no
need to insert mask/unmask or shift operations into
the expression RPN.

Alex

[muta...@gmail.com]

I don't quite understand your answer. I don't need a real
bitfield - I don't care if the variable is 1, 2 or 4 bytes in
size.

I'd just like to know how much work is involved to get a
bitfield to compile, while sticking to the RPN which seems
great to me.

Basically if any ": 1" or ": 2" etc was simply deleted, I
would be happy.

Rather than me having to delete it myself in GCC 3.4.6
so that I can use Smaller C to compile it.

But if ": 1" is in the same category as "+=" for floats,
that simply "deleting it" or "expanding it" is simple to
explain but very difficult to actually do (I love
computers!), then I'm not interested. I'll just delete
it myself and make a note to myself "don't use
bitfields - they prevent an RPN compiler from even
being able to ignore them".

Now that I know about RPN compilers, I wish to
support them in my own code as the "lowest
common denominator".

BFN. Paul.

[Alexei A. Frounze]

On Tuesday, April 6, 2021 at 1:27:58 AM UTC-7, muta...@gmail.com wrote:
> On Tuesday, April 6, 2021 at 5:41:44 PM UTC+10, Alexei A. Frounze wrote:
>
> > > Anyway, I have a new question. Smaller C (as documented)
> > > doesn't support bitfields. Is that because it is too difficult
> > > to parse using recursive descent? Note that I would be
> > > happy if unsigned int x : 1; was translated into simply
> > > unsigned int x. I don't care about saving space, I'm only
> > > interested in getting a compile to go through.
>
> > Besides additional parsing work (which isn't a big deal by itself),
> > it would require more complex internal declaration representation
> > and, most importantly, expression manipulation.
> > Like I said earlier, supporting += and such is complicated
> > precisely because of manipulating the expression's
> > Reverse Polish Notation.
> > Bitfields (and C99 bools for that matter) need a similar kind
> > of manipulation. Without bitfields, every . and -> simply accesses
> > 1, 2 or 4 bytes at (struct/union pointer + field offset), no
> > need to insert mask/unmask or shift operations into
> > the expression RPN.
> I don't quite understand your answer.

In simpler terms, in the absence of bitfields, . and -> directly
translate into e.g.
mov(sx|zx) reg1, [reg2 + const]
or
mov [reg1 + const], reg2/imm
as if . and -> were a shorthand for + in pointer arithmetic.

> I don't need a real
> bitfield - I don't care if the variable is 1, 2 or 4 bytes in
> size.
>
> I'd just like to know how much work is involved to get a
> bitfield to compile, while sticking to the RPN which seems
> great to me.

I didn't want to support bitfields in a very non-standard
fashion and I don't recommend it to others.

> Basically if any ": 1" or ": 2" etc was simply deleted, I
> would be happy.

In the simplest cases you could put then under #ifndef.
In more complex cases you could put them into a macro
that would conditionally (again, using #if(n)def) expand
into them or nothing.

> Rather than me having to delete it myself in GCC 3.4.6
> so that I can use Smaller C to compile it.

You're bold! :) I've only tried compiling LCC, but not
the beast GCC is.

> But if ": 1" is in the same category as "+=" for floats,
> that simply "deleting it" or "expanding it" is simple to
> explain but very difficult to actually do (I love
> computers!), then I'm not interested. I'll just delete
> it myself and make a note to myself "don't use
> bitfields - they prevent an RPN compiler from even
> being able to ignore them".
>
> Now that I know about RPN compilers, I wish to
> support them in my own code as the "lowest
> common denominator".

Don't think of it as a thing. Smaller C is probably the only
C compiler implementation that is so much more
complete than Small C that has RPN somewhat sticking
out. Other incomplete C compilers would likely have
many more limitations.

Alex

[muta...@gmail.com]

On Wednesday, April 7, 2021 at 1:25:48 AM UTC+10, Alexei A. Frounze wrote:

> I didn't want to support bitfields in a very non-standard
> fashion and I don't recommend it to others.

Why not? What's the downside? Perhaps it
could be a non-default compiler option?

> > Basically if any ": 1" or ": 2" etc was simply deleted, I
> > would be happy.

> In the simplest cases you could put then under #ifndef.
> In more complex cases you could put them into a macro
> that would conditionally (again, using #if(n)def) expand
> into them or nothing.

Sure. I'd just like to know how much work is involved
in getting the compiler to do that automatically.

> > Rather than me having to delete it myself in GCC 3.4.6
> > so that I can use Smaller C to compile it.

> You're bold! :) I've only tried compiling LCC, but not
> the beast GCC is.

I have converted GCC 3.2.3 and 3.4.6 into C90-compliant
programs. Especially the former. Unfortunately the
former uses K&R functions, and I'm not expecting
Smaller C to support that. Better to compile GCC 3.4.6
first, and then use that to compile GCC 3.2.3 which is
more stable.

> > Now that I know about RPN compilers, I wish to
> > support them in my own code as the "lowest
> > common denominator".

> Don't think of it as a thing. Smaller C is probably the only
> C compiler implementation that is so much more
> complete than Small C that has RPN somewhat sticking
> out. Other incomplete C compilers would likely have
> many more limitations.

It's more "what is the maximum that can reasonably
be done with RPN?" - answer - "Smaller C is a miracle
of engineering - just 14,000 lines of code". Ok, let's
adjust the C standard down to meet this technology.
PDOS has already been adjusted down with some
very minor changes with unitary operations on
floats (the changes are still perfectly C90).

BFN. Paul.

[muta...@gmail.com]

On Tuesday, April 6, 2021 at 4:10:29 PM UTC+10, Alexei A. Frounze wrote:

> > Or is it necessary to have a wasm-compatible
> > assembler that produces elf?

> Possibly JWASM would work. Never used it.

It works! To some extent, anyway. I can at least do
a link. New code is here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/smlstart.asm

The map detects some sort of difference though:

00000020 section .text:
(C code)

000102C0 section SMLSTART_TEXT:
(jwasm assembler code)

I'm currently working on getting my startup assembler
code to call a C function and return.

I know that all these functions are being stored as
flat addresses and need to be converted into
seg:offs.

Is there any reason this can't be done at link time,
ready for segment correction at load time by the
normal load process, instead of requiring special
startup code?

Thanks. Paul.

[Alexei A. Frounze]

On Friday, April 9, 2021 at 8:26:37 PM UTC-7, muta...@gmail.com wrote:
> On Tuesday, April 6, 2021 at 4:10:29 PM UTC+10, Alexei A. Frounze wrote:
>
> > > Or is it necessary to have a wasm-compatible
> > > assembler that produces elf?
>
> > Possibly JWASM would work. Never used it.
> It works! To some extent, anyway. I can at least do
> a link. New code is here:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/smlstart.asm
>
> The map detects some sort of difference though:
>
> 00000020 section .text:
> (C code)
>
> 000102C0 section SMLSTART_TEXT:
> (jwasm assembler code)

Without trying it myself, I'm not sure what this means.

> I'm currently working on getting my startup assembler
> code to call a C function and return.
>
> I know that all these functions are being stored as
> flat addresses and need to be converted into
> seg:offs.
>
> Is there any reason this can't be done at link time,
> ready for segment correction at load time by the
> normal load process, instead of requiring special
> startup code?

The normal process, per DOS .EXEs, is to add a 16-bit quantity
(the base segment where the .EXE image is loaded) to a
bunch of other 16-bit quantities (segments within the
program).

Direct function calls and accesses to global/static variables
both need to be relocated, but differently.
The normal process would at most handle the function calls.
So, instead of doing a half in the linker and a half in the
startup code or simply complicating the linker with the
segmentation details, I decided to fully do all of it in the
startup code.

Alex

[muta...@gmail.com]

On Saturday, April 10, 2021 at 2:45:51 PM UTC+10, Alexei A. Frounze wrote:

> > 000102C0 section SMLSTART_TEXT:
> > (jwasm assembler code)

> Without trying it myself, I'm not sure what this means.

I assume jwasm is naming text segments or
something like that. My assembler file is called
smlstart.asm.

I didn't see something in jwasm to stop inserting
stuff like that.

> The normal process, per DOS .EXEs, is to add a 16-bit quantity
> (the base segment where the .EXE image is loaded) to a
> bunch of other 16-bit quantities (segments within the
> program).
>
> Direct function calls and accesses to global/static variables
> both need to be relocated, but differently.

Oh. What's the difference? Isn't ds equal to cs in this
model?

> The normal process would at most handle the function calls.

> So, instead of doing a half in the linker and a half in the
> startup code or simply complicating the linker with the
> segmentation details, I decided to fully do all of it in the
> startup code.

By "complicate the linker", isn't it exacty the same code
as seen in the startup code, except written in C instead
of assembler?

In other words, a simplification?

Is it at least the same number of lines of code?

Maybe I can change smlrl myself if it is expected
to be the same number of lines of code. Much
easier than coding in assembler.

Or maybe I can write an external processor to
massage the executable produced by smlrl
(or a modified smlrl). Possibly reading the map
file too. But I need room in the smlrl-produced
executable to zap those relocations. Maybe
that's where the complication comes in - you
would need to introduce a relocation section
where none currently exists (PDOS/86 reports
0 relocations).

BFN. Paul.

[Alexei A. Frounze]

On Friday, April 9, 2021 at 11:06:20 PM UTC-7, muta...@gmail.com wrote:
> On Saturday, April 10, 2021 at 2:45:51 PM UTC+10, Alexei A. Frounze wrote:
>
> > > 000102C0 section SMLSTART_TEXT:
> > > (jwasm assembler code)
>
> > Without trying it myself, I'm not sure what this means.
> I assume jwasm is naming text segments or
> something like that. My assembler file is called
> smlstart.asm.

The file name is of little if any relevance.

> I didn't see something in jwasm to stop inserting
> stuff like that.
> > The normal process, per DOS .EXEs, is to add a 16-bit quantity
> > (the base segment where the .EXE image is loaded) to a
> > bunch of other 16-bit quantities (segments within the
> > program).
> >
> > Direct function calls and accesses to global/static variables
> > both need to be relocated, but differently.
> Oh. What's the difference? Isn't ds equal to cs in this
> model?

Direct calls are patched to be regular far calls to seg16:ofs16.
No such addressing exists for data.

> > The normal process would at most handle the function calls.
>
> > So, instead of doing a half in the linker and a half in the
> > startup code or simply complicating the linker with the
> > segmentation details, I decided to fully do all of it in the
> > startup code.
> By "complicate the linker", isn't it exacty the same code
> as seen in the startup code, except written in C instead
> of assembler?
>
> In other words, a simplification?

I don't think so.

> Is it at least the same number of lines of code?

Dunno.

> Maybe I can change smlrl myself if it is expected
> to be the same number of lines of code. Much
> easier than coding in assembler.

I don't see a problem in writing a page of assembly code
once and never having to change it. Or almost never.

> Or maybe I can write an external processor to
> massage the executable produced by smlrl
> (or a modified smlrl).

Adapting things to a different assembler only to get
the same results doesn't seem very useful.
NASM and YASM just work. You'd need to change
the generated syntax in the compiler as well.

I just tried converting c0dh.asm to JWASM and there
are a few problems.
1. I don't know if I can force it to generate segments with
a leading dot in the name; however, if all names lose
the dot, it may not be a problem at all
2. I don't know if I can force it to generate 16-bit code
(USE16 doesn't seem to work or make any effect)
3. Not sure if it would combine segment fragments
within one file (that is, multiple definitions of the same
segment interleaved with multiple definitions of other
segments) as if they continued each other textually,
ignoring segment and ends, without screwing things
up like aligning the fragments as if they were separate
segments of their own (this is the kind of problem in
FASM, which I fixed with the n2f wrapper)

JWASM may be a bad idea after all as it doesn't seem
to be able to mix 16-bit code and the 32-bit ELF format.

> Possibly reading the map
> file too. But I need room in the smlrl-produced
> executable to zap those relocations. Maybe
> that's where the complication comes in - you
> would need to introduce a relocation section
> where none currently exists (PDOS/86 reports
> 0 relocations).

There aren't any standard DOS .EXE relocations.
Custom relocations are in the .relot and .relod sections.

----8<----
;
; Copyright (c) 2014-2021, Alexey Frunze
; 2-clause BSD license.
;

; attempt to adapt from NASM to JWASM

.386
;bits 16

extern ___start__:byte
extern __start__relot:byte, __stop__relot:byte
extern __start__relod:byte, __stop__relod:byte
extern __start__bss:byte, __stop__bss:byte

;text segment "CODE" USE16
text segment "CODE"

public __start
;__start proc C USE16
__start:

; perform code/data relocations

call labnext
labnext:
xor ebx, ebx
mov bx, cs
shl ebx, 4
xor eax, eax
pop ax
add ebx, eax
sub ebx, offset labnext ; ebx = base physical address

mov esi, offset __start__relot
relo_text_loop:
cmp esi, offset __stop__relot
jae relo_text_done

lea edi, [ebx + esi] ; edi = physical address of a relocation table element

ror edi, 4
mov ds, di
shr edi, 28

mov edi, [di]
add edi, ebx ; edi = physical address of a dword to which to add ebx and which then to transform into seg:ofs far pointer

ror edi, 4
mov ds, di
shr edi, 28

mov eax, [di]
add eax, ebx

shl eax, 12
rol ax, 4

mov [di], eax

add esi, 4
jmp relo_text_loop
relo_text_done:

mov esi, offset __start__relod
relo_data_loop:
cmp esi, offset __stop__relod
jae relo_data_done

lea edi, [ebx + esi] ; edi = physical address of a relocation table element

ror edi, 4
mov ds, di
shr edi, 28

mov edi, [di]
add edi, ebx ; edi = physical address of a dword to which to add ebx

ror edi, 4
mov ds, di
shr edi, 28

add [di], ebx ; actual relocation

add esi, 4
jmp relo_data_loop
relo_data_done:

; Init .bss

push ebx

lea edi, [ebx + offset __start__bss]
lea ebx, [ebx + offset __stop__bss]
sub ebx, edi
ror edi, 4
mov es, di
shr edi, 28
xor al, al
cld

bss1:
mov ecx, 32768
cmp ebx, ecx
jc bss2

sub ebx, ecx
rep stosb
and di, 15
mov si, es
add si, 2048
mov es, si
jmp bss1

bss2:
mov cx, bx
rep stosb

pop ebx

lea eax, [ebx + offset ___start__]
shl eax, 12
rol ax, 4
push eax
retf ; __start__() will set up argc and argv for main() and call exit(main(argc, argv))
;__start endp

rt:
dd rt
text ends

relot segment "CONST"
dd rt ; .relot must exist for __start__relot and __stop__relot to also exist
relot ends

data segment "DATA"
rd:
dd rd
data ends

relod segment "CONST"
dd rd ; .relod must exist for __start__relod and __stop__relod to also exist
relod ends

bss segment "BSS"
; .bss must exist for __start__bss and __stop__bss to also exist
dd ?
bss ends

end
----8<----

Alex

[muta...@gmail.com]

On Saturday, April 10, 2021 at 5:20:47 PM UTC+10, Alexei A. Frounze wrote:

> > Oh. What's the difference? Isn't ds equal to cs in this
> > model?

> Direct calls are patched to be regular far calls to seg16:ofs16.
> No such addressing exists for data.

Ok, I'm guessing the data references are a flat
value and need to be "corrected" with the load
point of the module as an absolute value.

Yeah, I remember - 0xb8000 looked like it would work.

> I don't see a problem in writing a page of assembly code
> once and never having to change it. Or almost never.

Well, I struggle with assembler. I'm far more
productive with C.

> > Or maybe I can write an external processor to
> > massage the executable produced by smlrl
> > (or a modified smlrl).

> Adapting things to a different assembler only to get
> the same results doesn't seem very useful.

One day I hope someone will assemble it with masm,
as part of a commercial-quality product.

> NASM and YASM just work. You'd need to change
> the generated syntax in the compiler as well.

Replacing the compiler itself is a job for another
day, probably by someone else.

> I just tried converting c0dh.asm to JWASM and there
> are a few problems.
> 1. I don't know if I can force it to generate segments with
> a leading dot in the name; however, if all names lose
> the dot, it may not be a problem at all

Ok.

> 2. I don't know if I can force it to generate 16-bit code
> (USE16 doesn't seem to work or make any effect)

That should be governed by

.model large, c

right?

> 3. Not sure if it would combine segment fragments
> within one file (that is, multiple definitions of the same
> segment interleaved with multiple definitions of other
> segments) as if they continued each other textually,
> ignoring segment and ends, without screwing things
> up like aligning the fragments as if they were separate
> segments of their own (this is the kind of problem in
> FASM, which I fixed with the n2f wrapper)

Ok, over my head.

> JWASM may be a bad idea after all as it doesn't seem
> to be able to mix 16-bit code and the 32-bit ELF format.

I was able to get a clean link.

> ;
> ; Copyright (c) 2014-2021, Alexey Frunze
> ; 2-clause BSD license.
> ;
>
> ; attempt to adapt from NASM to JWASM

Ouch. I was doing it myself also because I wanted a clean
room implementation so that I could make it public domain
instead of BSD, for inclusion in PDOS.

Now people are going to see my code nearly identical to
yours and accuse me of stealing other people's code. :-(

Can I buy this code from you so that I can make it public
domain? How much do you want for it?

I also need to develop code for these functions:

public __lesf2
public __mulsf3
public __floatsisf
public __addsf3
public __negsf2
public __gesf2
public __divsf3
public __fixsfsi
public __subsf3

Maybe you could give me a price for them too?

They look like floating point, and I don't actually care about
floating point, at least at the moment, so I can leave them
dummied up.

But I need the relocation code.

Thanks. Paul.

[Alexei A. Frounze]

On Saturday, April 10, 2021 at 1:04:42 AM UTC-7, muta...@gmail.com wrote:
> On Saturday, April 10, 2021 at 5:20:47 PM UTC+10, Alexei A. Frounze wrote:
> > Adapting things to a different assembler only to get
> > the same results doesn't seem very useful.
> One day I hope someone will assemble it with masm,
> as part of a commercial-quality product.

I doubt MASM will work better.

> > 2. I don't know if I can force it to generate 16-bit code
> > (USE16 doesn't seem to work or make any effect)
> That should be governed by
>
> .model large, c
>
> right?

Nope. Disassemble it to see yourself.

> > 3. Not sure if it would combine segment fragments
> > within one file (that is, multiple definitions of the same
> > segment interleaved with multiple definitions of other
> > segments) as if they continued each other textually,
> > ignoring segment and ends, without screwing things
> > up like aligning the fragments as if they were separate
> > segments of their own (this is the kind of problem in
> > FASM, which I fixed with the n2f wrapper)
> Ok, over my head.

The compiler currently outputs code and data into the same
file as interleaved section fragments as soon as it can, so it
doesn't keep lots of stuff in memory, something like:

----8<----
section .data
foo:
db 1
dd my_string

section .rodata
my_string:
db "abc"

section .data
dd 2
----8<----

It expects the assembler to combine these fragments as if
they were contiguous in the source code:
----8<----
section .data
foo:
db 1
dd my_string
dd 2

section .rodata
my_string:
db "abc"
----8<----

If the 2nd .data fragment in the 1st snipped gets its own alignment,
then the 5-byte structure at foo (db+dd+dd) will be broken by
unexpected padding bytes.

> > JWASM may be a bad idea after all as it doesn't seem
> > to be able to mix 16-bit code and the 32-bit ELF format.
> I was able to get a clean link.

Close but no cigar?

> > ;
> > ; Copyright (c) 2014-2021, Alexey Frunze
> > ; 2-clause BSD license.
> > ;
> >
> > ; attempt to adapt from NASM to JWASM
> Ouch. I was doing it myself also because I wanted a clean
> room implementation so that I could make it public domain
> instead of BSD, for inclusion in PDOS.
>
> Now people are going to see my code nearly identical to
> yours and accuse me of stealing other people's code. :-(

Not sure there's a problem. Some stuff ought to be nearly
identical unless you want to artificially inflate or contort
it just to look different.

> Can I buy this code from you so that I can make it public
> domain? How much do you want for it?

$0.00. But I doubt any bank will be able to send that. :)

> I also need to develop code for these functions:
>
> public __lesf2
> public __mulsf3
> public __floatsisf
> public __addsf3
> public __negsf2
> public __gesf2
> public __divsf3
> public __fixsfsi
> public __subsf3
>
> Maybe you could give me a price for them too?

Except for the conversion(s), they are all trivial.
And the conversion is not too hard either,
if you can use x87 instructions.

Not sure what problem can be with these.
It's much like with Google vs Oracle over the min/max
functions which can be written in about one (or two)
ways only if you disregard formatting and naming:
int min(int a, int b) { return (a < b) ? a : b; }
Seriously.

You can add another $0.00.

If it helps, for some interoperability these functions are
named after the similar ones used by gcc and clang.
The only difference probably being that mine use float
instead of double (and a different calling convention).

> They look like floating point, and I don't actually care about
> floating point, at least at the moment, so I can leave them
> dummied up.
>
> But I need the relocation code.

Sure.

Alex

[muta...@gmail.com]

On Saturday, April 10, 2021 at 6:57:25 PM UTC+10, Alexei A. Frounze wrote:

> > > 2. I don't know if I can force it to generate 16-bit code
> > > (USE16 doesn't seem to work or make any effect)
> > That should be governed by
> >
> > .model large, c
> >
> > right?

> Nope. Disassemble it to see yourself.

I'm not sure what you're looking at. Can you
give me a specific instruction that you think
jwasm is generating incorrectly?

> > Ok, over my head.

> The compiler currently outputs code and data into the same
> file as interleaved section fragments as soon as it can, so it
> doesn't keep lots of stuff in memory, something like:

I'm not changing either Smaller C or nasm. I'm only
changing the startup code and the assembler
support routines.

So there is no .rodata

> > Now people are going to see my code nearly identical to
> > yours and accuse me of stealing other people's code. :-(

> Not sure there's a problem. Some stuff ought to be nearly
> identical unless you want to artificially inflate or contort
> it just to look different.

Once I reimplemented some GPL code. Both of us
were using C. Both of us used the same algorithm
(I don't actually know of any other algorithm that
could be used). I had read the code to understand
what the requirements were.

When I published my version, which was totally
different, because it was a complete rewrite,
someone said that all I had done was rename
variables and restructure the code.

> > Can I buy this code from you so that I can make it public
> > domain? How much do you want for it?

> $0.00. But I doubt any bank will be able to send that. :)

> > I also need to develop code for these functions:
> >
> > public __lesf2
> > public __mulsf3
> > public __floatsisf
> > public __addsf3
> > public __negsf2
> > public __gesf2
> > public __divsf3
> > public __fixsfsi
> > public __subsf3
> >
> > Maybe you could give me a price for them too?

> Except for the conversion(s), they are all trivial.
> And the conversion is not too hard either,
> if you can use x87 instructions.

I can use x87 instructions. I don't mind having
a requirement of a floating point coprocessor
if you wish to using floating point.

> Not sure what problem can be with these.
> It's much like with Google vs Oracle over the min/max
> functions which can be written in about one (or two)
> ways only if you disregard formatting and naming:
> int min(int a, int b) { return (a < b) ? a : b; }
> Seriously.

Correct. You can end up in court.

> You can add another $0.00.

Ok, thanks for the great pricing, but I need to be clear.

Can you please release any code you are happy to
make public domain with a clear "released to the
public domain" notice, no copyright statement, and
no caveats.

Or if you are uncomfortable about doing that, and
you're happy to accept $0.00, then maybe send me
an email with "Copyright Paul Edwards" on the code,
no conditions, not your responsibility, and I'll change
MY code (which it would now be) to release it to the
public domain.

My email address is muta...@gmail.com

> If it helps, for some interoperability these functions are
> named after the similar ones used by gcc and clang.
> The only difference probably being that mine use float
> instead of double (and a different calling convention).

That's all copyrighted code too. No use to me.

Thanks. Paul.

[Alexei A. Frounze]

On Saturday, April 10, 2021 at 2:17:22 AM UTC-7, muta...@gmail.com wrote:
> On Saturday, April 10, 2021 at 6:57:25 PM UTC+10, Alexei A. Frounze wrote:
>
> > > > 2. I don't know if I can force it to generate 16-bit code
> > > > (USE16 doesn't seem to work or make any effect)
> > > That should be governed by
> > >
> > > .model large, c
> > >
> > > right?
>
> > Nope. Disassemble it to see yourself.
> I'm not sure what you're looking at. Can you
> give me a specific instruction that you think
> jwasm is generating incorrectly?

Like, pretty much all of them are wrong?
If the code at __start is interpreted as 16-bit, then you get
00000240:E80000 calln file:00000243
00000243:0000 add [bx+si],al
00000245:33DB xor bx,bx
00000247:668CCB mov bx,cs
0000024A:C1E304 shl bx,04
0000024D:33C0 xor ax,ax
...

The .model directive doesn't change this. Nor does USE16.
You're still getting the code assembled for 32-bit mode.

Later,
Alex

[muta...@gmail.com]

On Saturday, April 10, 2021 at 7:45:33 PM UTC+10, Alexei A. Frounze wrote:

> > I'm not sure what you're looking at. Can you
> > give me a specific instruction that you think
> > jwasm is generating incorrectly?

> Like, pretty much all of them are wrong?
> If the code at __start is interpreted as 16-bit, then you get

__start is presumably your code, which I deliberately
avoided looking at, because I don't want to be accused
of stealing it if I need to write my own.

The only bit below where I can see something I
understand is this:

> 00000247:668CCB mov bx,cs

I can see an x'66' inserted which I don't think is
correct.

So I added the same instruction in my own code,
it assembled fine, and here is the disassembly:

0000 8C CB mov ebx,cs

It's true that it has put an unexpected "ebx" there, but
that's probably a bug, or limitation given that I'm
surprised wdis worked on ELF code in the first
place.

But you can see there is no x'66', which is what
we need.

I have already posted a link to my code if you want
to compare, and assuming I'm barking up the right
tree in the first place. :-)

BFN. Paul.

[Alexei A. Frounze]

On Saturday, April 10, 2021 at 3:17:02 AM UTC-7, muta...@gmail.com wrote:
> On Saturday, April 10, 2021 at 7:45:33 PM UTC+10, Alexei A. Frounze wrote:
>
> > > I'm not sure what you're looking at. Can you
> > > give me a specific instruction that you think
> > > jwasm is generating incorrectly?
>
> > Like, pretty much all of them are wrong?
> > If the code at __start is interpreted as 16-bit, then you get
> __start is presumably your code, which I deliberately
> avoided looking at, because I don't want to be accused
> of stealing it if I need to write my own.
>
> The only bit below where I can see something I
> understand is this:
>
> > 00000247:668CCB mov bx,cs
>
> I can see an x'66' inserted which I don't think is
> correct.

If you put my disassembly side by side with the source,
you'd see that the extended registers (eax, etc) and 16-bit
registers (ax, etc) took each others' places in most cases.
You'd also see an add instruction in the disassembly
right after the call instruction, but this add isn't in the source.
It's there because the call was generated for 32-bit mode
and so it's 2-bytes longer and those 2 extra bytes of the
offset are this add instruction.

IOW, when assembling into ELF, JWASM assumes 32-bit mode.

> So I added the same instruction in my own code,
> it assembled fine, and here is the disassembly:
>
> 0000 8C CB mov ebx,cs
>
> It's true that it has put an unexpected "ebx" there, but
> that's probably a bug, or limitation given that I'm
> surprised wdis worked on ELF code in the first
> place.

Not a bug. It just wasn't designed to support 16-bit
code properly when assembling into ELF files.

> But you can see there is no x'66', which is what
> we need.

So, you need to carefully "break" your source
in order for it to assemble into the encodings
proper for 16-bit mode.

Some examples:

call labnext
labnext:
----v----
db 0e8h
dw labnext - labnext
labnext:

xor ebx, ebx
----v----
xor bx, bx

mov bx, cs
----v----
mov ebx, cs

mov ds, di
----v----
mov ds, edi

pop ax
----v----
pop eax

sub ebx, offset labnext
----v----
db 66h
sub ebx, offset labnext

lea edi, [ebx + esi]

----v----
db 66h
db 67h

lea edi, [ebx + esi]

And there are more complex cases:

add esi, 4 ; there's a single byte immediate
----v----
add si, 4

mov ecx, 32768
----v----
mov cx, 32768
dw 0

add si, 2048 ; doesn't fit into a single byte immediate
----v----
db 81h, 0c6h, 0, 8

Not fun.

I'm not sure what you're gonna do with this.
Write your own assembler to work with Smaller C?

Alex

[muta...@gmail.com]

On Sunday, April 11, 2021 at 4:57:44 AM UTC+10, Alexei A. Frounze wrote:

> IOW, when assembling into ELF, JWASM assumes 32-bit mode.

Your examples are too complicated. I don't even
understand why you're not accepting my simple
example.

I'm using jwasm 1.94c

> > So I added the same instruction in my own code,
> > it assembled fine, and here is the disassembly:
> >
> > 0000 8C CB mov ebx,cs
> >
> > It's true that it has put an unexpected "ebx" there, but
> > that's probably a bug, or limitation given that I'm
> > surprised wdis worked on ELF code in the first
> > place.

> Not a bug. It just wasn't designed to support 16-bit
> code properly when assembling into ELF files.

I have no idea what you are talking about. wdis is
not producing a nice display, but it IS correctly
printing the bytes, and I confirmed from doing a
hexdump of the .obj file (ELF) that there is no
x'66'. It is working fine, and working differently
from what you showed.

As far as I can see, my jwasm is working fine
(and it runs under PDOS/86 too), and yours
isn't.

> > But you can see there is no x'66', which is what
> > we need.

> So, you need to carefully "break" your source
> in order for it to assemble into the encodings
> proper for 16-bit mode.

I didn't do anything special with my assembler
source. It worked fine out of the box. And it
*runs* fine too.

Although I haven't yet proven that I can call some
C code. I need some code to do a correction of
even a single function.

> I'm not sure what you're gonna do with this.
> Write your own assembler to work with Smaller C?

I don't understand your question.

Whenever an opportunity arises, I will replace a copyrighted
bit of software with a public domain bit of software.

Until then, I use copyrighted software such as gcc.

But even though I am happy to use gcc, or Smaller C,
for now, I will NOT put ANY copyrighted code into my
C runtime library. So I don't use glibc, I use PDPCLIB.
I don't use the Smaller C library, I use PDPCLIB. I don't
use the Smaller C startup code, I use my own.

I am happy to use any of your code that you are willing
to unconditionally release to the public domain.

But you (like most people) seem to have a reluctance
to do that. That's fine, it's your hard work, you can slap
whatever license you want on it. That's why I offered
to simply buy you out. I only need a page of your code,
or maybe a few pages depending on how big that
floating point stuff is. But you didn't give me a price.
You said I could have it for free, but I've seen no
public domain code, nor any code owned by me
(either will do the trick), heading my way. All I see is
copyrighted code, which I will not use. PDPCLIB is
about 30,000 lines of public domain code. I'm not
about to compromise the integrity of that to put in
100 lines of copyrighted code, no matter how great
someone things the alternative license is.

If your question is about the assembler itself, then
yes, my intention is to replace wasm (which can't
be used for commercial purposes) with an
assembler that can. But while still retaining
compatibility with Microsoft, so that industry
standard tools can be used to compile both my
assembler code and my C code. Rather than being
dependent on a format only "supported" by people
on the internet (nasm etc).

I don't care that Smaller C internally uses nasm. I
treat Smaller C + nasm as a single entity. It doesn't
make any difference to me if Smaller C generates
object code only, no assembler involved. That's not
the bit I'm trying to address. I'm trying to address
the startup code.

BFN. Paul.

[Alexei A. Frounze]

On Saturday, April 10, 2021 at 12:36:02 PM UTC-7, muta...@gmail.com wrote:
> On Sunday, April 11, 2021 at 4:57:44 AM UTC+10, Alexei A. Frounze wrote:
>
> > IOW, when assembling into ELF, JWASM assumes 32-bit mode.
> Your examples are too complicated. I don't even
> understand why you're not accepting my simple
> example.

I'm not seeing it work as needed on my end, which means that
either we're doing something differently or we're missing/ignoring
something. I'm fairly confident in that the result is wrong, and
we're timely getting to this...

> I'm using jwasm 1.94c

Um... I'd downloaded and built (with OW 1.9) this one:
https://github.com/JWasm/JWasm/archive/refs/tags/2.13.zip

You seem to be using the oldest from
https://sourceforge.net/projects/jwasm/files/

I seem to get the same or similar result with the 1.94c from here
as with the 2.13 from github.

> > > So I added the same instruction in my own code,
> > > it assembled fine, and here is the disassembly:
> > >
> > > 0000 8C CB mov ebx,cs
> > >
> > > It's true that it has put an unexpected "ebx" there, but
> > > that's probably a bug, or limitation given that I'm
> > > surprised wdis worked on ELF code in the first
> > > place.
>
> > Not a bug. It just wasn't designed to support 16-bit
> > code properly when assembling into ELF files.
> I have no idea what you are talking about. wdis is
> not producing a nice display, but it IS correctly
> printing the bytes, and I confirmed from doing a
> hexdump of the .obj file (ELF) that there is no
> x'66'. It is working fine, and working differently
> from what you showed.
>
> As far as I can see, my jwasm is working fine
> (and it runs under PDOS/86 too), and yours
> isn't.

OK. I've narrowed it down to these two lines:

.model large
.386

They must be in this order. If I swap them, I'll get
compilation for 32-bit mode, which is wrong.

> > > But you can see there is no x'66', which is what
> > > we need.
>
> > So, you need to carefully "break" your source
> > in order for it to assemble into the encodings
> > proper for 16-bit mode.
> I didn't do anything special with my assembler
> source. It worked fine out of the box. And it
> *runs* fine too.
>
> Although I haven't yet proven that I can call some
> C code. I need some code to do a correction of
> even a single function.
> > I'm not sure what you're gonna do with this.
> > Write your own assembler to work with Smaller C?
> I don't understand your question.

I was sure you were getting the same wrong output
as I was. Apparently, we weren't doing the same thing.

...

> You said I could have it for free, but I've seen no
> public domain code, nor any code owned by me
> (either will do the trick), heading my way.

I haven't gotten to it yet.

...

> If your question is about the assembler itself, then
> yes, my intention is to replace wasm (which can't
> be used for commercial purposes) with an
> assembler that can. But while still retaining
> compatibility with Microsoft, so that industry
> standard tools can be used to compile both my
> assembler code and my C code. Rather than being
> dependent on a format only "supported" by people
> on the internet (nasm etc).

It's been there for years in NASM and YASM and I'm sure
older releases will stick around, unlike older
Microsoft tools with their backward compatibility.

Alex

[muta...@gmail.com]

On Sunday, April 11, 2021 at 6:39:31 AM UTC+10, Alexei A. Frounze wrote:

> OK. I've narrowed it down to these two lines:
>
> .model large
> .386
>
> They must be in this order. If I swap them, I'll get
> compilation for 32-bit mode, which is wrong.

Great! I dodged a bullet there. I copied the code
from existing code I had, to get the syntax right,
but there was no ".386" in the code I copied. I
have previously seen people use ".386p" and I
wondered what that actually meant, so did a
google search and found out that I actually
wanted ".386", so added that, luckily after the
".model".

> > > I'm not sure what you're gonna do with this.
> > > Write your own assembler to work with Smaller C?
> > I don't understand your question.

> I was sure you were getting the same wrong output
> as I was. Apparently, we weren't doing the same thing.

When dealing with computers, I'm never 100%
sure of anything. I won't even bet that
"if (4 == 4)" will test true on every compiler, or
even the same compiler on different runs. :-)

> > You said I could have it for free, but I've seen no
> > public domain code, nor any code owned by me
> > (either will do the trick), heading my way.

> I haven't gotten to it yet.

Got your email - thanks!

> > If your question is about the assembler itself, then
> > yes, my intention is to replace wasm (which can't
> > be used for commercial purposes) with an
> > assembler that can. But while still retaining
> > compatibility with Microsoft, so that industry
> > standard tools can be used to compile both my
> > assembler code and my C code. Rather than being
> > dependent on a format only "supported" by people
> > on the internet (nasm etc).

> It's been there for years in NASM and YASM and I'm sure
> older releases will stick around, unlike older
> Microsoft tools with their backward compatibility.

I don't care how many releases of nasm stick around.
They deliberately chose a syntax different from
industry-standard masm. I don't know what their game
is, but I'm not buying it, and I don't expect commercial
enterprises producing a professional operating system
to buy it either. Obviously they can if they want to, I
just don't expect it to be something universally
acceptable. If Microsoft starts accepting nasm syntax,
maybe that would be acceptable. Maybe.

BFN. Paul.

[muta...@gmail.com]

On Sunday, April 11, 2021 at 6:39:31 AM UTC+10, Alexei A. Frounze wrote:

> > You said I could have it for free, but I've seen no
> > public domain code, nor any code owned by me
> > (either will do the trick), heading my way.

> I haven't gotten to it yet.

Hi Alexey.

Thanks so much for your email with the public domain
code for the startup and support code. I combined them
and committed them to Sourceforge unchanged, and
you can find them here:

https://sourceforge.net/p/pdos/gitcode/ci/7aadfb666e5e915c9bdcdc41f04ae4209d738683/tree/pdpclib/smlstart.asm

I will report progress.

BFN. Paul.

[muta...@gmail.com]

On Sunday, April 11, 2021 at 1:29:37 PM UTC+10, muta...@gmail.com wrote:

> I will report progress.

As you noted, unless I upgraded to a newer version of
jwasm, I was going to get this:

C:\devel\pdos\pdpclib>jwasm -elf -Dmemodel=large smlstart.asm -Fosmlstart.obj
JWasm v1.94c, Dec 24 2008, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.

smlstart.asm(148): Error! E226: Fixup invalid for ELF: 6
smlstart.asm(148): Error! E226: Fixup invalid for ELF: 6
smlstart.asm(148): Error! E226: Fixup invalid for ELF: 6
smlstart.asm(148): Error! E226: Fixup invalid for ELF: 6
smlstart.asm(148): Error! E226: Fixup invalid for ELF: 6
smlstart.asm(148): Error! E226: Fixup invalid for ELF: 6
smlstart.asm(148): Error! E226: Fixup invalid for ELF: 6
smlstart.asm: 148 lines, 2 passes, 16 ms, 0 warnings, 7 errors

Another thing I noticed is that the code doesn't work with
normal wasm:

C:\devel\pdos\pdpclib>wasm -Dmemodel=large smlstart.asm -Fosmlstart.obj
Open Watcom Assembler Version 1.6
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
smlstart.asm(92): Error! E083: Label is expected
smlstart.asm(93): Error! E083: Label is expected
smlstart.asm(120): Error! E083: Label is expected

That code looks like this:

lea edi, [ebx + offset __start__bss]

I noticed this code:

mov esi, offset __start__relod

doesn't have an error, so I wonder if, for the one that
doesn't work, I can do a mov into esi also.

Anyway, rather than give up on my old version of jwasm,
I decided to try out objcopy, like this:

jwasm -coff -Dmemodel=large smlstart.asm -Fosmlstart.obj
(no error from jwasm)

C:\devel\pdos\pdpclib>objcopy -O elf32-i386 smlstart.obj temp.obj
BFD: temp.obj: unsupported relocation type (null)
objcopy:temp.obj: Bad value

So it looks like I'm going to have to bite the bullet and
upgrade jwasm.

From memory, later versions of jwasm don't work on
Freedos so I was reluctant to upgrade.

Unless the problem can be fixed by addressing those
wasm errors that may be fixed with esi.

BFN. Paul.

[Rod Pemberton]

On Sat, 10 Apr 2021 12:36:00 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:


> I will NOT put ANY copyrighted code into my C runtime library.

Unfortunately, most EU countries don't legally recognize public domain,
i.e., without copyright. Everything is automatically copyrighted under
their laws and treaties, i.e., legally belongs to someone. Public
domain (no copyright, no owner) seems to primarily be a US legal
concept, due to the US government producing works for use by it's
people and corporations, i.e., the public. Unfortunately, it's never
been legally tested in the US as to whether public domain is allowed
for US citizens. I.e., public domain is only known to be legally
allowed for works of the US government. In other words, your code
should probably be copyrighted and licensed liberally, e.g., a liberal
FOSS license such as a 2- or 3- clause BSD or MIT license. I say
probably because I'm not aware of Australian law, but also because
you're likely wanting others to work on and contribute to your project,
in which case, your copyrights or lack thereof should be compatible
with the laws other countries, which lack a public domain concept.
(Sorry about the run-on sentence ...)

Comments on copyrights usually spark arguments. So, I hope not ...

--
Security breaches. Tax haven leaks. Someone is searching for a needle
in a haystack, but the needle isn't there.

[muta...@gmail.com]

On Sunday, April 11, 2021 at 5:23:26 PM UTC+10, Rod Pemberton wrote:

> > I will NOT put ANY copyrighted code into my C runtime library.

> Unfortunately, most EU countries don't legally recognize public domain,
> i.e., without copyright. Everything is automatically copyrighted under
> their laws and treaties, i.e., legally belongs to someone. Public

This is not true. What do you think the status of
Shakespeare's "Hamlet" is in the EU? GPL v2?

What is different in SOME countries (not the US
which is my first target) is that you can't actually
relinquish your copyright and put it in the public
domain, so that it is in the same status as "Hamlet".

For that I provide a CC0 fallback in PDOS.

> domain (no copyright, no owner) seems to primarily be a US legal
> concept, due to the US government producing works for use by it's
> people and corporations, i.e., the public. Unfortunately, it's never
> been legally tested in the US as to whether public domain is allowed
> for US citizens. I.e., public domain is only known to be legally
> allowed for works of the US government.

Are you saying that no-one who released their work
to the public domain (with an explicit notice, and
no caveats) has then attempted to turn
around and sue someone for using "their" code?

That's not really surprising, is it?

And you're claiming the US government *has* done
that, ie taken some citizen to court for copyright
infringement and the courts told the government
to fuck off?

IF that happened, it might have been because the
US government didn't put an explicit "released to
the public domain" on their work so were hoping
to retain an implicit or explicit copyright.

BFN. Paul.

[muta...@gmail.com]

On Sunday, April 11, 2021 at 5:23:26 PM UTC+10, Rod Pemberton wrote:

> allowed for works of the US government. In other words, your code
> should probably be copyrighted and licensed liberally, e.g., a liberal

Also, out of curiosity, what do you think actually happens
in the EU (or even the US) if you write:

Released to the public domain.
You can use this code for any purpose whatsoever
without restriction.


I note that copyright is implied, the moment you write
your code, even without an explicit notice (in recent
decades, anyway).

What do you think happens if you refrain from converting
an implicit copyright into an explicit copyright? ie why
would you feel the need to write the word "Copyright"?
ie what is the legal difference between implicit and
explicit copyright, anywhere on the planet?

What do you think happens if you explicitly write the
phrase "released to the public domain"? In the worst
case, EU (or Mars) courts would just ignore that, it
is harmless. Or you think what? Writing the phrase
"public domain" means that anything else that is
written is invalidated and replaced with "anyone who
uses this code can be sued, because the writer was
obviously insane"? So it is a dangerous thing to write,
unlike the word "copyright", which is completely harmless?

What do you think happens when courts see the sentence
"You can use this code for any purpose whatsoever"? Do
you think they say "oh no, that is invalidated because he
didn't write the word 'copyright', so what we're going to
do is make it illegal for anyone to use this work, and if
anyone does use this work, they can be sued by either
the original author, or the government, or indeed, any
random member of public, for billions of dollars, for
copyright infringement"?

So that is why you come to the conclusion that you
"need" an explicit copyright, followed by a lot of
conditions for lawyers to argue the meaning of?

BFN. Paul.

[muta...@gmail.com]

On Monday, April 12, 2021 at 6:13:22 AM UTC+10, muta...@gmail.com wrote:

> > domain (no copyright, no owner) seems to primarily be a US legal
> > concept, due to the US government producing works for use by it's
> > people and corporations, i.e., the public. Unfortunately, it's never
> > been legally tested in the US as to whether public domain is allowed
> > for US citizens. I.e., public domain is only known to be legally
> > allowed for works of the US government.

> Are you saying that no-one who released their work
> to the public domain (with an explicit notice, and
> no caveats) has then attempted to turn
> around and sue someone for using "their" code?
>
> That's not really surprising, is it?

Also, 0 cases is a pretty good track record considering
that is the whole point - a company can use my public
domain code (or "Hamlet") and there's no-one at all
who is going to sue them.

If someone did sue them (e.g. one of Shakespeare's
descendants), I would hope that there was some legal
recourse for the company to recoup costs from that
descendant for wasting everyone's time. The same as
if I personally sued you for even READING "Hamlet",
even though I'm not even a descendant.

And regarding testing in courts, even assuming that
a case is tested all the way up to the Supreme Court,
that still doesn't provide a definitive answer, as there
can be a new Supreme Court ruling.

Including, theoretically, a new Supreme Court ruling
that gives me the right to sue you for reading "Hamlet".

Or, theoretically, a new Supreme Court ruling that makes
it illegal for me to use my own code, even if I stick a
"Copyright Paul Edwards, all rights reserved" notice on it.

Or, theoretically, Biden may be pissed off at one of my
tweets calling him "Sleepy Joe" and may choose to
nuke Sydney.

Or maybe he'll nuke you because you don't have a valid
email address.

I have seen the High Court of Australia completely make
up shit that is "implied" by our constitution (they reversed
a ban on political advertising because of that).

I have seen the Australian constitution, which explicitly
says that the Governor General controls the navy,
completely ignored.

And it's not just Australia. In the US election in 2000,
almost half of the Supreme Court attempted to change
election rules on the fly when their guy lost.

Nothing is guaranteed.

"Released to the public domain", with no caveats, is as
good as you're ever going to get. With CC0 fallback if
you want to be pedantic.

BFN. Paul.

[Rod Pemberton]

On Sun, 11 Apr 2021 13:42:18 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:

> On Sunday, April 11, 2021 at 5:23:26 PM UTC+10, Rod Pemberton wrote:
>
> > allowed for works of the US government. In other words, your code
> > should probably be copyrighted and licensed liberally, e.g., a
> > liberal
>

> What do you think happens if you explicitly write the
> phrase "released to the public domain"? In the worst
> case, EU (or Mars) courts would just ignore that, it
> is harmless.

Ignored. Yes.
Harmless. No.

The people using the code wouldn't have the legal right to use it.

E.g., a 3rd party could sue your users to prevent their use of your
freely given code. I.e., say a small business (2nd party) uses your
"public domain" code to provide a service (SaaS) for profit. However,
another business, with their own competing commercial software that
they're licensing for profit, sues to prevent usage of the free code by
the first business by claiming that the first business is using your
code illegally under the existing copyright laws. If the court
enforces copyright law, then your users are out-of-business. If the
court grants an exception to the law, based on the intent of your
public domain claim, then the court is creating or allowing for a
public domain exclusion. I doubt that most courts would set new
precedent here.

[muta...@gmail.com]

On Monday, April 12, 2021 at 10:12:33 AM UTC+10, Rod Pemberton wrote:
> On Sun, 11 Apr 2021 13:42:18 -0700 (PDT)
> "muta...@gmail.com" <muta...@gmail.com> wrote:
>
> > On Sunday, April 11, 2021 at 5:23:26 PM UTC+10, Rod Pemberton wrote:
> >
> > > allowed for works of the US government. In other words, your code
> > > should probably be copyrighted and licensed liberally, e.g., a
> > > liberal
> >
> > What do you think happens if you explicitly write the
> > phrase "released to the public domain"? In the worst
> > case, EU (or Mars) courts would just ignore that, it
> > is harmless.
> Ignored. Yes.
> Harmless. No.
>
> The people using the code wouldn't have the legal right to use it.

You're strictly talking some non-US countries
here, right?

> E.g., a 3rd party could sue your users to prevent their use of your
> freely given code. I.e., say a small business (2nd party) uses your
> "public domain" code to provide a service (SaaS) for profit. However,
> another business, with their own competing commercial software that
> they're licensing for profit, sues to prevent usage of the free code by
> the first business by claiming that the first business is using your
> code illegally under the existing copyright laws. If the court
> enforces copyright law, then your users are out-of-business. If the
> court grants an exception to the law, based on the intent of your
> public domain claim, then the court is creating or allowing for a
> public domain exclusion. I doubt that most courts would set new
> precedent here.

This would be a very strange situation. Someone trying
to enforce copyright claims on someone else's behalf,
ie me, even if they (ie me) are totally unwilling?

Let's make it more realistic, that I'm attempting to enforce
copyright claims on my own code, despite the fact that I
released it with a specific "released to the public domain"
notice, and no copyright statement whatsoever.

You believe that in European Country X (and let's say I'm
even a citizen of that country too), that I can take a
small business to court (also registered in Country X),
and ask the court to ignore my explicit "public domain" notice
(which you believe they are happy to do), and rely on
the "implied copyright" (since there is no explicit
copyright), and then demand compensation.

That's a realistic scenario to you?

What if my implicit (NOT explicit!) copyright is then followed
by a statement that you can do whatever you want with this
code? How on earth is that different from explicit copyright +
license?

What if I explicitly say you can follow CC0? How is that
any worse than explicit copyright + license?

Even just in Weird Country X, nevermind the US.

BFN. Paul.

[Rod Pemberton]

On Sun, 11 Apr 2021 19:20:44 -0700 (PDT)

"muta...@gmail.com" <muta...@gmail.com> wrote:

> On Monday, April 12, 2021 at 10:12:33 AM UTC+10, Rod Pemberton wrote:
> > On Sun, 11 Apr 2021 13:42:18 -0700 (PDT)
> > "muta...@gmail.com" <muta...@gmail.com> wrote:
> > > On Sunday, April 11, 2021 at 5:23:26 PM UTC+10, Rod Pemberton
> > > wrote:

> > > > allowed for works of the US government. In other words, your
> > > > code should probably be copyrighted and licensed liberally,
> > > > e.g., a liberal
> > >
> > > What do you think happens if you explicitly write the
> > > phrase "released to the public domain"? In the worst
> > > case, EU (or Mars) courts would just ignore that, it
> > > is harmless.
> >
> > Ignored. Yes.
> > Harmless. No.
> >
> > The people using the code wouldn't have the legal right to use it.
>
> You're strictly talking some non-US countries here, right?

Not necessarily ... Other countries are tied to EU copyright laws via
treaties. E.g., US Federal government, but not US State governments.

Yes.

When profit is involved, anything goes, including sabotage and
corruption, but also to simply force your competition to comply with
all relevant laws, using a fair playing field as a pretext to do so, so
that you actually have a competitive advantage.

The EU and EU companies are masters of this type of legal abuse to
ensure a home court competitive advantage. The EU would reject the
import of vehicles made in the US simply because the paint was slightly
scuffed during shipping. This was an issue which was fixable on EU
soil. However, EU law required the vehicles to be returned to the US to
be fixed and re-shipped. The EU also prohibited the US from exporting
food products to the EU with common place names, because the names
matched cities or regions in the EU, e.g., champagne, parmesan, etc, as
if the EU has a legal right to monopolize them. China just doesn't
allow foreign companies into their market unless the US company
forfeits their technology for the "greater good" of China, i.e.,
protectionism, mercantilism.

> What if my implicit (NOT explicit!) copyright is then followed
> by a statement that you can do whatever you want with this
> code? How on earth is that different from explicit copyright +
> license?

One is legal. One isn't. Courts enforce the law. If the issue makes
it to a court, they'll enforce the law no matter how bizarre. The law
isn't being contested.

E.g., Nazi Germany committed numerous atrocities because it was the
law. Some of the first laws they passed were gun registration and gun
confiscation. They failed to head the words of Niccolo Machiavelli:

"There never was a new prince who has disarmed his subjects; rather
when he has found them disarmed he has always armed them, because, by
arming them, those arms become yours, those men who were distrusted
become faithful, and those who were faithful are kept so, and your
subjects become your adherents. ... But when you disarm them, you at
once offend them by showing that you distrust them, either for
cowardice or for want of loyalty, and either of these opinions breeds
hatred against you," said Niccolo Machiavelli in The Prince.

> What if I explicitly say you can follow CC0? How is that
> any worse than explicit copyright + license?

I don't know/recall what CC0 is. I'm assuming CC0 is some form of a
"copyleft" license, i.e., copyright + license.


Sigh, it seems my hope not statement went ignored yet again ...

[muta...@gmail.com]

On Monday, April 12, 2021 at 6:34:42 PM UTC+10, Rod Pemberton wrote:

> When profit is involved, anything goes, including sabotage and
> corruption,

We're talking purely legal things here.

> but also to simply force your competition to comply with
> all relevant laws, using a fair playing field as a pretext to do so, so
> that you actually have a competitive advantage.

I've never heard of someone trying to sue someone else
for copyright violation, against the wishes of the original
author.

It is more realistic that the author attempts to enforce
copyright.

> > What if my implicit (NOT explicit!) copyright is then followed
> > by a statement that you can do whatever you want with this
> > code? How on earth is that different from explicit copyright +
> > license?

> One is legal. One isn't. Courts enforce the law. If the issue makes
> it to a court, they'll enforce the law no matter how bizarre. The law
> isn't being contested.

I have no idea what you are talking about. Why is an
implicit copyright not legal?

And even if it is not legal, what is the status of the
work in that Country X with no explicit copyright?

> law. Some of the first laws they passed were gun registration and gun
> confiscation. They failed to head the words of Niccolo Machiavelli:

Guns are pretty rare in Australia too, and there was some
confiscation done about 20 years ago or something, after
some mass murder, and we've never had a mass murder
since.

Guns in the hands of citizens are useless against an
army. People don't buy very expensive tanks and planes
and guns for fun. If you want to be able to defeat
government forces, you shouldn't have allowed the
government to construct a modern, extremely deadly,
military.

Don't believe the myths of "glorious guerillas".

> > What if I explicitly say you can follow CC0? How is that
> > any worse than explicit copyright + license?

> I don't know/recall what CC0 is. I'm assuming CC0 is some form of a
> "copyleft" license, i.e., copyright + license.

It is public domain for weird countries that supposedly
don't allow you to get your work into the same status
as "Hamlet":

https://creativecommons.org/publicdomain/zero/1.0/

And I ask the question again.

How is explicit public domain (which you think will be
ignored by courts in Country X - or you think will actually
cause some harm, but I don't follow your logic there),
implied rather than explicit copyright (you haven't
explained why implied is a problem), plus CC0, is
inferior to anything else you care to name.

Noting that my primary target is not Country X, but the
USA, where the very first thing "released to the public
domain" is all that is required to say "case closed".

BFN. Paul.

[James Harris]

On 10/04/2021 22:33, muta...@gmail.com wrote:
> On Sunday, April 11, 2021 at 6:39:31 AM UTC+10, Alexei A. Frounze wrote:

...

> I don't care how many releases of nasm stick around.
> They deliberately chose a syntax different from
> industry-standard masm. I don't know what their game
> is, but I'm not buying it, and I don't expect commercial
> enterprises producing a professional operating system
> to buy it either. Obviously they can if they want to, I
> just don't expect it to be something universally
> acceptable. If Microsoft starts accepting nasm syntax,
> maybe that would be acceptable. Maybe.

Microsoft does not set the standard for what assembly source should look
like. They have one syntax, other assemblers use other syntaxes. That's
all. Microsoft is a commercial company. It is not a standards body. It
is not even the commercial company which produced the CPU.


--
James Harris

[muta...@gmail.com]

On Sunday, April 11, 2021 at 2:28:33 PM UTC+10, muta...@gmail.com wrote:

> Unless the problem can be fixed by addressing those
> wasm errors that may be fixed with esi.

I was indeed able to get wasm to accept the code with
some small changes, but I couldn't see any way to get
it to generate anything except OMF.

Actually I didn't know it was OMF at the time, it was
just showing up as an 8086 relocatable.

So for the first time ever I started actually inspecting
object code, and matching it to Wikipedia, to find out
what I was dealing with. I decided to try my hand at
an OMF to ELF converter, to see if I can use wasm
instead of upgrading jwasm. So far I've got as far as
parsing an OMF file and matching most codes with
Wikipedia.

https://en.wikipedia.org/wiki/Relocatable_Object_Module_Format

So currently in my work I deal with OMF, COFF, ELF
and a.out.

BFN. Paul.



/*********************************************************************/
/* */
/* This Program Written by Paul Edwards. */
/* Released to the Public Domain */
/* */
/*********************************************************************/
/*********************************************************************/
/* */
/* objcnv.c - convert OMF to ELF */
/* */
/*********************************************************************/

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
FILE *fp;
FILE *fq;
long pos;
unsigned char *buf;
unsigned char *p;
unsigned int len;

if (argc <= 2)
{
printf("usage: objcnv <omf file> <elf file>\n");
return (EXIT_FAILURE);
}

fp = fopen(*(argv + 1), "rb");
if (fp == NULL)
{
printf("failed to open %s for input\n", *(argv + 1));
return (EXIT_FAILURE);
}

fseek(fp, 0, SEEK_END);
pos = ftell(fp);
rewind(fp);
buf = malloc((size_t)pos); /* better hope less than 64K on MSDOS! */
if (buf == NULL)
{
printf("can't allocate %ld bytes\n", pos);
return (EXIT_FAILURE);
}

fread(buf, (size_t)pos, 1, fp);

p = buf;
while (*p != 0x8a)
{
printf("record type %02X\n", *p);
p++;
len = p[1] << 8 | p[0];
printf("len is %u\n", len);
p += 2; /* skip length */
p += (len - 1); /* position on checksum */
printf("checksum %02X\n", *p);
p++;
}
return (0);
}

[muta...@gmail.com]

On Tuesday, April 13, 2021 at 9:02:31 PM UTC+10, James Harris wrote:

> Microsoft does not set the standard for what assembly source should look
> like. They have one syntax, other assemblers use other syntaxes. That's
> all. Microsoft is a commercial company. It is not a standards body. It
> is not even the commercial company which produced the CPU.

I'm from the late 1980s. As far as I know, everyone
was trying to be masm-compatible.

I'm not sure if/when people started deviating from
that.

I don't write much assembler, but when I do, I try to
keep it in a format that is acceptable to masm, tasm
and wasm. Although I only ever tested with the latter
two (which I bought), and now only ever use wasm
(or jwasm).

BFN. Paul.

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Tuesday, April 13, 2021 at 9:02:31 PM UTC+10, James Harris wrote:
>
>> Microsoft does not set the standard for what assembly source should look
>> like. They have one syntax, other assemblers use other syntaxes. That's
>> all. Microsoft is a commercial company. It is not a standards body. It
>> is not even the commercial company which produced the CPU.
>
>I'm from the late 1980s. As far as I know, everyone
>was trying to be masm-compatible.

That's not the case. Besides, real programmers were
using Unix in the 1980s - even on x86.

Hence the Intel syntax vs. AT&T syntax ongoing debates in
the X86 assembler world.

[muta...@gmail.com]

On Wednesday, April 14, 2021 at 12:46:18 AM UTC+10, Scott Lurndal wrote:

> >I'm from the late 1980s. As far as I know, everyone
> >was trying to be masm-compatible.

> That's not the case.

The only exception I know of was tasm's "ideal"
mode, which I never touched, precisely because
I didn't want to tie myself down to one manufacturer.

> Besides, real programmers were
> using Unix in the 1980s - even on x86.

In the 1980s, I was able to afford a C64, an
IBM PC XT with 20 MB hard disk and monochrome
monitor (cost AUD$2000 at the time), and an
Amiga 500.

At work we were using MVS/XA, and I did ask my
boss why we didn't switch to Unix and he said it
couldn't handle multi-volume tapes as one reason.

I wrote all my software C90-compliant, which meant
it ran on every system except the C64, which I wasn't
actually using anymore, and I used micro-emacs as
my editor, which worked everywhere except MVS.

I then essentially embarked on a decades-long quest
to get micro-emacs to run on MVS, and while I was
at it, get MSDOS (a C version, recompiled) to run on
the mainframe too.

At the time I didn't know what the limitations were.

When I found them, I broke them.

I did know about POSIX, and when I saw it had fork()
in it, I had nothing but disgust for Unix.

In the last few days I was dismayed to find out that
even going back to Python 3.3, it is riddled with POSIX
crap instead of having a C90-compliant option (as
default, too). Even one that is only capable of doing
a print "hello, world" or whatever Python syntax is.

I need Python in order to (attempt to) run an MVS
assembler on an environment other than MVS.

So, if a refusal to jump on the Unix bandwagon
means that I am a nancy boy instead of a "real
programmer", feel free to call me a nancy boy.

Someone else said I couldn't program my way
out of a paper bag, so I'm used to it.

> Hence the Intel syntax vs. AT&T syntax ongoing debates in
> the X86 assembler world.

Ok, this is pretty sad. I did actually write some
assembler in gas syntax as produced by GCC 3.2.3.
Can't remember which one that is.

But I want to replace it, probably with something that
assembles with wasm, and hopefully masm. But that
probably means weaning myself off a.out, which I
have been using for 25 years (thanks to EMX 0.9d).

BTW, I actually made changes to wasm, that are in
the official releases, to make it actually usable, even
for the minimal assembler programming I was doing.

To get off a.out, and presumably on to PE/COFF, I
need to get off binutils 2.14a which doesn't seem to
allow me to create relocatable executables. Actually
even the a.out is only working because I am using
"-r" in an unusual way. I might do this by switching
to Smaller C rather than attempting to upgrade to
binutils 2.23. Although I need the dlltool as well.

But I am expecting to switch from PD-Windows to
PDOS-generic, so the executables won't be compatible
with anything at all anyway. They will need to be
relocatable though. I'll probably stick with PE/COFF
so that the tools are the same though. But maybe this
is where Smaller C fits in. No DLLs required. And maybe
poasm as well. Or maybe there will be so little assembler
in PDOS-generic (just setjmp/longjmp) that I can write
my own masm-compatible assembler (with just enough
support to assemble setjmp/longjmp).

Maybe I should make my objcnv produce COFF, and then
build objcopy myself to see what the issue is converting
from COFF to ELF, prior to Smaller C working for PDOS/86.

BFN. Paul.

[muta...@gmail.com]

On Tuesday, April 13, 2021 at 9:08:23 PM UTC+10, muta...@gmail.com wrote:

> So currently in my work I deal with OMF, COFF, ELF
> and a.out.

I was wondering how Watcom managed to support
building Windows executables when wasm didn't
produce COFF.

It turns out that wcl386 doesn't produce COFF either.
It produces OMF!!!

Therefore OMF is good enough to support 32-bit,
and not just for OS/2.

BFN. Paul.

[muta...@gmail.com]

On Sunday, April 11, 2021 at 2:28:33 PM UTC+10, muta...@gmail.com wrote:

> So it looks like I'm going to have to bite the bullet and
> upgrade jwasm.
>
> From memory, later versions of jwasm don't work on
> Freedos so I was reluctant to upgrade.

The minor change I made to my old jwasm was all
that was required to get everything working.

I now have a glorified "hello, world" built with Smaller C
working on Freedos and PDOS/86.

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/

This is fantastic!

Thanks Alexey!!!

There's still some more work to be done in PDPCLIB to
get some other stuff working, but I'm not expecting any
dramas.

BFN. Paul.

[muta...@gmail.com]

On Monday, April 5, 2021 at 5:34:51 AM UTC+8, Alexei A. Frounze wrote:

> - bootstrapping (I don't have an x86 compiler with plain ints being 64-bit)

Someone suggested a simple solution to this.

gcc -Dint="long long"

Would that work?

BFN. Paul.