FreeDOS support

[josie87]

Just tried in kubuntu. Compiling works now. Will test in FreeDos now

[pohmelie]

Really can't realize why this wont work with Arch, but if djgpp stdlib file missed, then it's djgpp issue.

[josie87]

Really can't realize why this wont work with Arch, but if djgpp stdlib file missed, then it's djgpp issue.

yep. I also don't understand. Djgpp built without an error... Rebuilt a few times - no sucess. Anyone else on Arch?


Checked out freshly built uPy in FreeDos. Works great and startup is really fast compared to pythonD.

[pfalcon]

ideal solution would be to just use existing unix makefile and port directory

Are you sure this is the best solution?

Yes, from the maintenance perspective, yes.

Cause I think, that FreeDos have very little with unix build, not about Makefile difference, but… this is very different operating systems.

Depending on your outlook, that's no true. ANSI C requires a particular API to be provided by a C toolchain, beyond that, there's POSIX API, and nowadays any full-fledged OS largely complies with it, beyond that, there's Python API, which is largely single, portable API, not a per-OS API. So, there're differences between various OSes, but they only emphasize their similarity.

I think more, than win and unix are. Also, FreeDos build requires proper environment variables, so there should be readme/guide, something like in my repo right now. So it's not just easy as "make freedos".

So, if we discuss whether there should be separate top-level dir for DJGPP port, you and I can't decide that, that's largely up to dpgeorge. I personally don't have strong objection to that, except for a generic one that there're hundreds various OS environments, and we can't have a top-level dir for each. My point is that what changes are required for a minimal DJGPP port to build - I'd personally like to see that requiring at most an mpconfigport.h file. If there's a separate dir, then Makefile and README are fine too of course. So, if there're any changes to other files are required, I'd like to have them reviewed and merged.

[pfalcon]

pfalcon
I'm not sure if it is a real issue. I've just remove alloca.h, as it done in arm builds (with stdlib.h):
https://github.com/pohmelie/micropython ... 6927ddea62

Well, if you needed originally to work it around by pretending to be a FreeBSD, then of course it's a real issue. Fixed now.

[pfalcon]

Some review comments on https://github.com/pohmelie/micropython-freedos

First of all, great work, pohmelie! It's definitely useful as it is, hopefully not just for you.

But it's not done in the best way for long-term maintenance. For example, you seem to just have copied most of unix/ directory contents into your repository, including bunch of C files, like input.c. So, first of all, it's not clear whether you made any changes to them or not while copied. Next, if any of files in unix/ are updated (e.g., bugs fixed), duplicates in your repo will stay old and broken. That's why all choices should be driven by the easy of maintenance (which includes never duplicating files or effort, and making as minimal changes as possible in general).

Some comments about "dos" module you wrote. First of all, again, if you needed it, it's OK to have it - that's certainly how everyone does it - if one needs something adhoc, one does it in adhoc way for oneself. But if you look at Python documentation https://docs.python.org/3/library/ , you won't see "dos" module there. And that's good reason for not having it. Also, looking at the contents of your module, you duplicated functionality of standard "time" module there (time-related functions), and functionality of MicroPython standard "machine" and "uctypes" modules (memory access).

That's easily overlooked difference between Python and many other "embedded" language of Lua. With Lua, people usually create adhoc APIs on spot. Everyone does it like, so all APIs are different and incompatible. That's not how Python works. It's well known motto is "batteries included", what means that vast set of standard APIs is provided. Any particular implementation may miss some APIs, but if it's done, then it should be done using standard API. If CPython lacks some APIs, like for example raw hardware access, we follow the same approach with MicroPython still - define common API, which every port is encouraged to implement, and every port is discouraged to implement it another way. And we make it easy for ports to have it, as underlying implementation is portable and reusable (well, may be not the case for everything yet, but that's our direction).

So, again, it's ok to have your personal "dos" module - there're tens of thousands of such 3rd-party Python modules. It's just can't be part of the official DJGPP port.

[pohmelie]

if any of files in unix/ are updated (e.g., bugs fixed), duplicates in your repo will stay old and broken

True.

looking at the contents of your module, you duplicated functionality of standard "time" module there (time-related functions), and functionality of MicroPython standard "machine" and "uctypes" modules (memory access).

Not at all. There is dpmi and real-protected bridge, so there is protected memory and real memory. Access for them is different, and should have different naming(?).

if you look at Python documentation https://docs.python.org/3/library/ , you won't see "dos" module there

True. Definetly "dos" module should not be in micropython repo, no discuss.

That's easily overlooked difference between Python and many other "embedded" language of Lua

Agree, dos functions should be implemented in terms of micropython/python api.

I will try to create «minimal» build inside unix directory. Is it ok to ask questions about unix makefile and review code here?

[pfalcon]

looking at the contents of your module, you duplicated functionality of standard "time" module there (time-related functions), and functionality of MicroPython standard "machine" and "uctypes" modules (memory access).

Not at all. There is dpmi and real-protected bridge, so there is protected memory and real memory. Access for them is different, and should have different naming(?).

That's the difference between machine.mem8/16/32 - this allows to access "physical" memory. uctypes.bytes_at/uctypes.bytearray_at() work with "virtual" (per-process) memory. This might cover your usecases, if not, we'd like to know details to see if it would be possible to cover them.

I will try to create «minimal» build inside unix directory. Is it ok to ask questions about unix makefile and review code here?

Sure.

[pohmelie]

That's the difference between machine.mem8/16/32 - this allows to access "physical" memory. uctypes.bytes_at/uctypes.bytearray_at() work with "virtual" (per-process) memory. This might cover your usecases, if not, we'd like to know details to see if it would be possible to cover them.

How about block copy for "physical" and "virtual"? Cause djgpp "physical" memory access is expensive. Also, can't find some common machine module description in /py. Does it have standard/template?

About makefile. What is the best way to make freedos build in unix directory? make djgpp? make freedos? I'm not familar with makefiles at all. Can I change variables(?) like CFLAGS_MOD inside target code(?)

Code: Select all

freedos:
    CFLAGS_MODE += something

[dhylands]

If you're going to do this using the unix Makefile in the unix directory, rather than use make freedos I would probably do something like:

Code: Select all

make TARGET=freedos

and then inside the Makefile you can do things like:

Code: Select all

ifeq ($(TARGET),freedos)
    CFLAGS += freedos CFLAGS
else
    CFLAGS += unix CFLAGS
endif

I've had the default TARGET be building the unix platform as it is now. For testing you can create a GNUmakefile (note the lowercase m) which contains:

Code: Select all

$(info Executing GNUmakefile)
TARGET = freedos
$(info TARGET = $(TARGET))
include Makefile

and then you can just use

Code: Select all

make

and it will build freedos for you. The GNUmakefile is not something we check into the repository so this allows you to override common setting if you always use one particular TARGET or other make flags.