FreeDOS support

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
josie87
Posts: 24
Joined: Tue Jun 30, 2015 2:46 pm

Re: FreeDOS support

Post by josie87 » Thu Dec 03, 2015 1:12 pm

Just tried in kubuntu. Compiling works now. Will test in FreeDos now :-)

pohmelie
Posts: 55
Joined: Mon Nov 23, 2015 6:31 pm

Re: FreeDOS support

Post by pohmelie » Thu Dec 03, 2015 1:34 pm

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

josie87
Posts: 24
Joined: Tue Jun 30, 2015 2:46 pm

Re: FreeDOS support

Post by josie87 » Thu Dec 03, 2015 2:35 pm

pohmelie wrote: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
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: FreeDOS support

Post by pfalcon » Sat Dec 05, 2015 10:30 am

pohmelie wrote:
pfalcon wrote: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.
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: FreeDOS support

Post by pfalcon » Sat Dec 05, 2015 10:34 am

pohmelie wrote: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.
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: FreeDOS support

Post by pfalcon » Sat Dec 05, 2015 11:28 am

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.
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

pohmelie
Posts: 55
Joined: Mon Nov 23, 2015 6:31 pm

Re: FreeDOS support

Post by pohmelie » Sat Dec 05, 2015 2:59 pm

pfalcon wrote:if any of files in unix/ are updated (e.g., bugs fixed), duplicates in your repo will stay old and broken
True.
pfalcon wrote: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(?).
pfalcon wrote: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.
pfalcon wrote: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
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: FreeDOS support

Post by pfalcon » Sat Dec 05, 2015 4:48 pm

pohmelie wrote:
pfalcon wrote: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.
pohmelie wrote: I will try to create «minimal» build inside unix directory. Is it ok to ask questions about unix makefile and review code here?
Sure.
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

pohmelie
Posts: 55
Joined: Mon Nov 23, 2015 6:31 pm

Re: FreeDOS support

Post by pohmelie » Sun Dec 06, 2015 1:00 pm

pfalcon wrote: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

User avatar
dhylands
Posts: 3268
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: FreeDOS support

Post by dhylands » Sun Dec 06, 2015 7:29 pm

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.

Post Reply