M3PC.96 (m3bin.exe, m3src.exe) ??
Daniel Benavides
http://groups.google.com/group/comp.lang.modula3/browse_thread/thread/b3ddcdc2f6d5ff8f/f72a1b30db82b226?lnk=raot
thanks for the info, I think would be good make a diff, instead of C
we could make something about to generate just smaller footprint code,
I wonder how much can be done in the threading, there used to be some
threading c kernel. Anyway I had a Professor a bit fan of OS/2 back in
its time, for doing a web server as research project, not sure if he
got Modula-3 in his hands to play in OS/2, anyway will ask him too
what he remembers.
I have heard of another M3DOS compiler, Curtis Jewell non-TSR (he has
a web page of his own:
http://poli.cs.vsb.cz/misc/rbint/text/2D00.html
), but would like to hear your opinion on that. Also heard from yet
another one but not sure if for DOS, the 80186 platform, I'm not too
keen about asking but 4 mb minimum, would like to run in less. There
is some discussion on opencm3.net lately, about C-- target (normally
the easier to port the harder to optimize in space and in time, but
anyways if we got everything to compile in C-- ).
Another and already done alternative in the C channel that certainly
would be fan to watch is with Link Time optimization tool chain, using
an intermediate translation (from Modula-3 C to Intermediate rep):
http://www.cs.princeton.edu/research/techreps/TR-490-95
Also if we could make cm3 there is some potential way to save AST
pickled, but need more disk space for this, could help in some cases
(or floppies in case of cross compilations, or a way to bootstrap the
sources from the older ones if so, perhaps would mean djgpp hacking or
a native backend, if there is one, or application to make it from
scratch, see:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.27.3456
or port from NT386 cg-burs interface available in pm3, basic code
there should be the same).
So basically could be two or three circuit:
SRC M3 -> M3CG -> CLEF ->C -> MLCC -> MlDD
M3 PC -> C ->MLCC -> MLDD
And potentially re targeting:
SRC M3 -> M3CG-burs (usually a bit faster in compilation time) ->
DJGPP
Thanks in advance
- Ocultar texto citado -
2011/7/8 Rugxulo <rug...@gmail.com>
Hi,
On 7/8/11, Daniel <dabena...@gmail.com> wrote:
>
> about your M3 inquiry, i have a copy of m3src96.exe, (I
downloaded from
> archive.org) but waited until your search was done, did you get
genuine copy
> finally?
> Thanks in advance
EDIT: With your permission, it might just be easier to post this
e-mail verbatim to the newsgroup. While it explains my perspective
(and attempts) very well, it's probably not likely to generate any
interest. But I dunno ....
Well ... I also found m3src.exe (.ZIP sfx) on Wayback
(archive.org) a
few months ago, but then I couldn't find it again, and only had
one
copy of that file on a (later disconnected) machine. In the past
week,
I reconnected that old machine (for other reasons) and grabbed the
file. I intended to post about it, but I never did (mainly due to
pessimism about any interest, esp. since license is apparently non-
GPL
friendly, "non-commercial only" ??, which means any GPL zealots
wouldn't mirror it for me anyways, ugh).
Why? Well, for one, I never found m3bin.exe (also .ZIP sfx), and I
never got any other reply (esp. not from Laszlo). I tried at least
twice rebuilding '96 with M3/PC '94 (raw FreeDOS and later in
DOSEMU,
which was much faster), but it didn't work, which really sucks. So
it
will need some tweaking to rebuild.
The only main advantage to '96 is that it uses DJGPP v2 instead of
(old old, a.out [sic]) DJGPPv1. Hence '94 won't run under WinXP at
all
(except VERY slowly under DOSBox 0.74). Plus v1 stuff won't
(directly)
compress with UPX (and actually by default seems to always leave
debug
symbol info in the output, ugh).
Months ago I also (unsuccessfully) tried running ex32 on this same
machine (raw DOS), but the "extender" (XMS only) didn't work, no
surprise. (Heh, 128 MB is usually too low, but I suspect in this
case
it was too high. Argh.) I even almost e-mailed Klaus Preschern
personally about it, but I've been having Internet woes too, so I
didn't bother him (yet). BTW, he was involved in both DOS ports
(as
well as later OS/2 3.6).
EDIT: I'll just cc him here, hopefully he won't mind. :-/
Yeah, it's sad that the only DOS compiler(s) for Modula-3 barely
work
and are old old old, not even latest 3.6 from DEC SRC. :-(
Reading the PM3 website acts like it would "only take a few days"
to
port to a new platform. It can't be THAT hard: there are at least
two
or three threading libs for DJGPPv2. Also, v2 supports LFNs out of
the
box, so we could get rid of all the dumb hacks / workarounds
(filename
mapping) which wouldn't be needed anymore (even in raw DOS, LFN
TSRs
exist and work fairly well).
But I wonder if anyone on Earth besides me cares. Worse is that
CM3 /
Win32 needs MSVC linker (annoying) and PM3 / Win32 (Cygwin) didn't
build correctly for me. Of course, I prefer DOS anyways, but if a
DJGPPv2 version worked, it would work on WinXP too.
So it's frustrating. Perhaps if I can get M3/PC '94 to build, I
can
then diff between '96 sources and see what changes were made. Then
I
could rebuild '96 with newer DJGPP. Or perhaps if I can figure out
how
to manually recompile the libs (m3? m3local? gpl?) for '94, then I
could run m3.exe (-keep ??) manually and compile the output .c
files
with newer DJGPP also. Then it would maybe work.
But I don't know when I'll bother trying that again. It's not that
I
won't, just got other minor things to do too. I should probably
post
about all this on the newsgroup, but it seems almost nobody reads
there anymore. Besides, I don't even barely understand Modula-3,
haven't fully gotten a grasp on the object model or anything. I
only
wrote a few hundred lines in it for one very very simple program
(Befunge-93 interpreter, heh), so I'm FAR from a pro! But I'm one
of
those people that wants to preserve everything that used to work,
e.g.
DJGPP / DOS stuff.
P.S. FreeDOS kernel 2040 released about two weeks ago. So DOS
ain't
dead yet. ;-) But I haven't mentioned any of this to them
explicitly (they have enough to do). I do vaguely volunteer for
them
from time to time but nothing major (no kernel tweaks or anything).
Daniel Benavides
ok, I found recently this machine representations for OO VLDB, one of
them Galileo, used in Sun and MSDOS:
http://www.vldb.org/journal/VLDBJ4/P403.pdf
There is yet another one which can be played on assuming that many
other systems as well, here is the document but it's just a skeleton,
draft.
http://wenku.baidu.com/view/32cb1c07cc17552707220833.html
It would to seek info on their papers in PHOLAM case they were trying
to optimize RDBMS as OODBMS, could be a good starting point for a
complete DB system in Modula-3.
Thanks in advance
On Jul 8, 10:57 pm, Daniel Benavides <dabenavid...@gmail.com> wrote:
> Hi:http://groups.google.com/group/comp.lang.modula3/browse_thread/thread...
> 2011/7/8 Rugxulo <rugx...@gmail.com>
>
> Hi,
Daniel Benavides
yes, in fact the Modula-3 implementation of SystemF is on Fsub, it was
used to apply a logical deduction of Modula-3 type system, it could be
that if smartened (it has actually inference), could be put in some
Modula-3 (Obliq) clothes and put it to run again.
http://lucacardelli.name/Artifacts/Fsub/Fsub%20(v1.6.0,%20M3%20v3.6).zip
http://lucacardelli.name/Topics/Quest/Quest.zip
In fact the same language is used to implement yet another abstract
machine the Quest, for which there were more development, later.
Luca is a smart man, no doubts, but anyways we need to strong support
their style of programming before can make any progress (Nt based
station comes to mind perhaps time to ask there too pm3-src disk, had
a good system (optional cross compilation which feels good also), but
this yet another problem, migrate all the goodness to CM3, it could be
hard but fun, and BTW update the bootstrapping problem and solution of
bigger language there, so double fan, or say m3pc triple fun, still
would need to address the M3CG issue in djgpp)
More looking into imp-ç or ç-calculus or impÇ as you want, gives more
answers about the real influence, even today:
http://eprints.mdx.ac.uk/6842/1/scico_aspfun.pdf
http://www.ibr.cs.tu-bs.de/cm/events/tubs.CITY-symposium-2009/slides/Kammueller_Florian.pdf
A thesis
http://opus.kobv.de/tuberlin/volltexte/2010/2691/pdf/sudhof_henry.pdf
for Aspect-oriented programming their paper:
http://eprints.mdx.ac.uk/6858/1/scpaper.pdf
And the mechanized verification framework (as what Cardelli realized
in its Fsub):
http://www.cis.upenn.edu/~sweirich/wmm/wmm07/programme/slides/kamueller.pdf
http://eprints.mdx.ac.uk/6858/
http://iv.tu-berlin.de/TechnBerichte/2007/2007-20.pdf
http://hal.inria.fr/inria-00121816/en/
Besides some more applications on lambda calculus and translation and
attribute grammars:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.70
There is also something in mind that come back to you, but continuing
this trend, OK, so here we say, we think efficiency is good (yeah I
agree, up to some point, where vagueness is so wide that the system
becomes almost untouchable, so many tools, optimizers, which is just
that I don't like, but if time spent in them is not useful which I
haven't proved then it follows it's no optimum, so I can part from
that to show a contradiction to prove it's OK to do it, so a cost/
benefit list could be good idea, but anyways, if we can prove the
system does OK, I believe is enough for certain real time and critical
applications to do it, I perhaps know of some ones like nuclear
applications, chemical reactors, etc, alike, high-loaded servers):
http://phd.di.unipi.it/Theses/PhDthesis_Cataudella.pdf
Ok, I agree with the world looking for lock-free programming but in
SMP systems this are relevant for any fine developed application, so
perhaps this comes to mind when we get to program SMPs, which is near
at some point, but in the nearest is the locking perspective enough
for getting later better threaded applications:
Thanks in advance
Hi,
On 7/12/11, Daniel <dabena...@gmail.com> wrote:
>
> I have found a recent investigation on abadi-cardelli object calculus,
> besides one of cardelli's ambient calculus abstract machines:
>
> http://www.brics.dk/RS/08/5/BRICS-RS-08-5.pdf
>
> http://www.brics.dk/RS/08/5/BRICS-RS-08-6.pdf
>
> http://web.archive.org/web/20070715094955/http://www.aaue.dk/~av/tesiphd.ps
I have no idea what that means. ;-) But at least I vaguely
recognize the name (naturally).
http://en.wikipedia.org/wiki/Luca_Cardelli
BTW, Luca would probably be interested since that interview he gave
(two or three years ago) said M3 was still his favorite language. But
of course he's "moved on" to greener pastures, apparently F#. I was a
little surprised that his Wikipedia page failed to mention M3 at all
!! (If I wasn't so preoccupied with other things, I might've added it
there. Heh, but no, I probably shouldn't cc him here. But feel free!)
> But anyway I can't stand not having threads, if not possible at all, we
> could somehow emulate via time slicing, but the threading stop is still true
> an issue, so would need for better or worse the last CM3 RT.
It would have threads, similar to old M3/PC, but would probably not be
pre-emptive. (M3/PC needed an additional explicit yield call.) It's
probably possible but unlikely. Anyways, like I said, it's been
halfway done for DJGPP before, see lwp (preemptive), clwp
(cooperative), GNU pth (cooperative), FSU pthreads (?).
> By the way, here there is another copies of M3PC:
> http://web.archive.org/web/20040725051000/http://www-lufgi3.informatik.rwth-aachen.de/SOFTWARE/M3PC/
Hmmm, amazing, it has m3bin.exe (.ZIP sfx) and "unzip -t" didn't find
any errors! It just might work! (Will have to try later.) Either way,
you should forward this URL to the newsgroup so somebody can mirror it
(hopefully).
> I hope this helps a bit, thanks in advance, my bigger dream would become
> this at some point computer recycled (of course hardware manufacturing but
> since many years ago, this was explained in computer magazines, I wonder why
> not, in cases of damaged video cards, etc, but even if not an embedded OS
> like SPINE or SPIN in a decent intelligent NIC would be enough).
I've never tried SPIN. I'm not sure you could even do so without
downloading old old FreeBSD and old old Linux and building from
sources (ugh). I think they used their own compiler, or at least
heavily modified, but I'm not sure. But yeah, would be interesting
Rugxulo
On Jul 13, 1:37 am, Daniel Benavides <dabenavid...@gmail.com> wrote:
>
> > By the way, here there is another copies of M3PC:
> >http://web.archive.org/web/20040725051000/http://
> >www-lufgi3.informatik.rwth-aachen.de/SOFTWARE/M3PC/
Only very briefly tested it, but it seems to work. It uses DJGPP 2.0,
GCC 2.7.2.1, BinUtils (LD, etc) 2.7, etc. Of course I used a newer
CWSDPMI, and for now I only tested in native FreeDOS.
And yes, you can finally UPX the binaries, thankfully, and they really
need it!! You can also rename the DJGPP dir (but have to change \m3\lib
\*.cnf or whatever and/or %CCTOP%) and use a drive other than C:\, so
that's good too. I also briefly switched to GCC 2.95.3 + DJGPP 2.03p2,
and it mostly? worked, but I'll have to try more later.
I didn't try any of Laszlo's book examples (yet), but I did rebuild
the compiler. That seems to still work (unlike '94 trying to build
'96). I think using a cache (e.g. UIDE), putting c:\m3 and c:\djgpp
first in %PATH%, and pointing %TMPDIR% to RAM drive (e.g. RDISK) help
the speed a lot (since it's not exactly blazingly fast).
It does complain if I try accessing FileIO.i3 saying it can't find it.
If I manually try putting it in current dir, then it says hash mixup /
duplicate. For good or bad, I have no idea how to "correctly" fix
that, for now, but using "FileStream" instead seems to work *exactly*
the same!
I'm a bit confused about the license, e.g. the RTL sources explicitly
mention non-commercial only (and of course giving back pretty much all
rights to DEC). My only real complaint about that (since I'm just
tinkering) is that most GPL fans won't mirror the thing. I really
don't want it to be lost to the ages. (It was already pretty hard to
find!) Unfortunately, I don't think it's acceptable to Berlios or
SourceForge.
Anyways, well at least it's *something*! Now of course to test harder
and learn a bit. Then, who knows ....