sorry, I never tried cross-compiling. I started here:
http://en.wikipedia.org/wiki/Cross_compiler#GCC_and_cross_compilation, and
http://www.cis.upenn.edu/~milom/cross-compile.html
what should be switch --target=some-target set to?
your best bet is to cross-compile on Linux. set GOOS to
That's what I was saying. We are working in nix in such a way that we
hope the code we are working on could be used by the stock Plan 9
in the future. So, it's a fork, but we are still trying to cooperate with
everyone else.
Branching seems to be a black hole, though: there is no easy way to
surely it only makes sense that when forks appear the knives come out.
I guess this is part of the reason I follow 9fans so avidly :-)
++L
I have great respect for Geoff and what he has been and continues to
do for Plan 9.
I'd like to add my voice to this. And I take exception to Schmidt
taking the glory for cwfs, which is Geoff Collyer's work and is not in
any way to be treated as a sequel to Fossil.
++L
I'm impressed by the work Geoff, and others do on Plan9, and I'm not
talking about 9front at all.
Jim, Charles, and others made an excellent port for amd64,
which is cleaner that any other system I've seen. We used that
as a starting point for nix.
Out of curiosity: 9front makes high claims
I take full responsibility for the misunderstandings, though
I wonder why we're all so credulous when it comes to articles on
websites.
Because that's the point of journalism. You ought to have made sure
that the community affected by the article was informed about its
inaccuracies. I do
so it is childish to replace 9load? or build a distribution that
uses the stable and robust cwfs instead of fossil? write an
audio layer? moving realmode and keyboard processing to userspace?
unify the boot process to to break into rc shell, so one can
at see what hardware got detected, poke
A handful of device drivers have been written from scratch. Some
devices started working when their PCI IDs were added to existing
drivers.
A bit like pulling teeth, isn't it? It is natural to become defensive
of one's efforts, but that also leads to categorising those against
whom defenses
theres a new miniport originaly based on the ac97 driver for the
audio devices.
sb16 driver was rewritten mainly to get interrupt free output
[... snip ...]
Yeow!
no #P/realmode anymore. no 16bit code in kernel, e820 scan
done by bootloader.
thats all i can remember for hardware
I have written some go code on linux and i want to move it under 9
thanks, regards, ++pac
your best bet is to cross-compile on Linux. set GOOS to plan9 and GOARCH to
386.
That's a nice idea, but I haven't had much joy in the last few days
trying that. I haven't tried a tagged release,
okay, I'll try all three possibilities, however, how to extract files from
lucio's go.ext? I see that it is plain text... thanks, ++pac
disk/mkfs, see the man page (man mkext). But I'd rather hand you a
fresher release, if you can be patient. Right now I need a new web
proxy as the
i'm well aware we can tweak go and remove better error messages. that
doesn't count IMHO. We're working to get to the point where we don't
tweak the go source at all and it just builds. I don't see the point
in making a go for Plan 9 that is in some way compromised. So, getting
back to my
I've been toying with the idea of re-implementing a SPAM reporting
system in Go under Plan 9
I will be posting to sources my mostly functional release of Go for
Plan 9. I have successfully generated godoc using entirely a Plan 9
platform and my next step is to make sure that this can be
My guess is that the ARM compiler does not like 64-bit values in
conditional expressions. The following C snippet:
typedef unsigned long long uvlong;
uvlong uvinf= ((uvlong)0x7FF032)|0x;
uvlong uvneginf = ((uvlong)0xFFF032)|0x;
i've tried this example with a cc that has com64.c unchanged from sources
(ie, without the change erik suggested),
and a 5c that has no relevant changes at all, and it was fine.
I'm too stupid to reach the right conclusion from what you are saying:
does this mean that I have a dated 5c? I'm
i've got a 5[acl] tucked away that does 64-bit operations, although
i think that particular case can be fixed more simply.
Will you please upload what you can find somewhere public?
I don't know the ARM at all, but the convergence of Go, Android and
64-bit ARM chips in mobile phones can't be
/sys/src/cmd/cc/com64.c:275,281
The context is:
int
com64(Node *n)
{
...
switch(n-op) {
default:
diag(n, unknown vlong %O, n-op);
case OFUNC:
n-complex = FNX;
case ORETURN:
sorry, i was misleading. i meant a 5c that does vlongs more directly,
not a 5c that does the new arm 64-bit operations. that compiler would
have a different name.
I seem to recall that ARM 64-bit emulation is one of Go's open TODOs.
I think thie plethora of (sub-)architectures is terribly
i've just copied across and compiled cc and 5c from sources,and that
code you posted earlier compiled without fuss.
Hm, that needs investigating, I know I have messed around with 5[acl]
for the Sheeva, but I expected regular replicas to take care of that.
Mind you, that's bad thinking, as
what do they do with nanosleep?
Don't know, really.
perhaps they are simply implementing a profiling system themselves
because the operating system might not provide a suitable one.
This is Go, so I'm sure they are looking for a uniform approach. I
guess they looked too hard?
perhaps plan
after looking at the source, i'd say nanosleep is the least of your troubles.
You think that once it compiles, it will not work as required? I have
not looked very deeply under the bonnet, so I must have missed
important details.
++L
ppmaps might just work (depending on libmach, i suppose).
also, although it's supposed to profile at regular real-time intervals,
it seems to assume that regularity will just happen. perhaps it does.
I do wonder who assembled all these tools, I have found enough
mixtures of Plan 9
Oops, a heavy handed comment intended to amuse Charles rather than be
critical of the Go Authors. I do not intend to offend anyone and I
apologise if I did.
++L
---BeginMessage---
ppmaps might just work (depending on libmach, i suppose).
also, although it's supposed to profile at regular
just take unsuitable things out of the mkfiles, since no other system
is using those.
I was discussing with Ron the fact that in the longer term goinstall
ought to supersede both gmake (at last!) and mk, in building Go. I
guess it needs to deal with situations like the present one kind of a
right now i'm in dire need of someone in the bay area with strong plan
9 experience and/or deep knowledge of intel hardware platforms. if
you know of anyone who might be interested, please let them know to
send me an email.
You wouldn't be needing a South African with an Italian (EU)
For a first pass, you could create a nanosleep for plan 9 that rounds
to milliseconds and then use sleep()
Sounds like a plan, because the man page for nanosleep() expects the
underlying resolution to be implemented. The complexities of does
not interact with signals can probably be ignored
I'm not familiar enough with Linux and APT to figure this one out:
what are the prerequisites for 9vx that are not intrinsically met by a
standard UBUNTU installation? The immediate need is related in some
way to x11-draw, but that is not the name of an apt package.
++L
You may wish to install the apt-file package, then you could do
apt-file search x11-draw in order to know which package provides it.
Now, that's a piece of useful information, thank you. APT is so
unhelpful regarding trying to get any information out of it.
++L
I'm heading for Europe early next week, for some five weeks. Sadly, I
will not be able to attend IWP9 in Madrid, but my thoughts will
certainly be with those who will be there.
Anyway, I have more or less tidied up the Go release so that it is
possible to compile the Go toolchain (linker,
issuing multiple outstanding
messages is how protocols like aoe, pcie, etc. get speed. writes are posted.
the question for me is how does one make this easy and natural. one way
is to allow the mnt driver to issue multiple concurrent reads or writes for
the same i/o. another would be to
Plan9front's porting is just one shot. However, it's very nice one shot,
because I can do, say, 'godoc image' on my Plan 9 system.
All the neccessary commands can be compiled on my Plan 9 system, etc.
Well, I hope I didn't state this too strongly, I certainly have only
indirect evidenmce of
goos.c is meant to be in src/lib9, I need to start up my laptop to
check that in fact it is a module I added specially for Plan 9.
Lucio, what is the difference between your purpose and the one
I installed (plan9fron?). By your attention, I found Russ's repository
of 'go for plan9', and
what's a good recipe for making goose? :)
I omitted
(src)
(...)
lib9
goos.c
from /go/devproto. Please add goos.c and its containing directory.
There are one or two gotchas. I have tidied up, but they may be
lurking on your system from earlier instances:
On /n/sources/contrib/lucio/go there is a fresh version of my efforts.
It is a bit ahead of my submissions to the Go Authors and could
benefit from inspection from the Plan 9 perspective. Also, this
inevitably means that there will be changes required by the code
reviewers.
At this point, it
: # bind -b ... : exit status=rc 308216: rc 308218: mk 308220: error
fyi, instead of /go, i've copied it to $home/go and:
aux/stub -d /go
bind -c $home/go /go
-Skip
On Mon, Aug 1, 2011 at 2:04 AM, Lucio De Re lu...@proxima.alt.za wrote:
On /n/sources/contrib/lucio/go there is a fresh version of my
mk ROOT=$home/go
mk 'ROOT='^$home/go
seems better, if uglier :-)
++L
mk in 8l
8c -I/go/include -I/go/386/include -FTVw asm.c
8c -I/go/include -I/go/386/include -FTVw ../ld/data.c
mk: no recipe to make 'goos.8' in directory /go/src/cmd/8l
mk: # bind -b ... : exit status=rc 308216: rc 308218: mk 308220: error
goos.c is meant to be in src/lib9, I need to start
While attempting to compile Bison (yeah, still gnawing at that
bone!) I have managed to jam cpp more or less solid. That's compiling
scan-code-c.c which reduces to compiling scan-code.c.
However, it does not seem to be Bison that's at fault: it seems that an
invocation of alloc() tries to set a
On Mon, Jul 25, 2011 at 10:42:11AM -0400, Russ Cox wrote:
However, it does not seem to be Bison that's at fault: it seems that an
invocation of alloc() tries to set a lock and never succeeds or gives up.
It's possible that you've found a latent bug in malloc.
However, that malloc has
On Fri, Jul 22, 2011 at 05:36:42AM +, arn...@skeeve.com wrote:
Does Go use things that are bison-specific? If not, maybe Berkeley Yacc
(there are various versions around) would be easier to port.
That's why I ask about Bison experts, it's hard to tell how deep the
usage of
On Fri, Jul 22, 2011 at 12:42:12AM -0700, Bakul Shah wrote:
$ yacc gc/go.y
yacc: e - line 120 of go.y, syntax error
%error-verbose
^
This is a bison dropping. I haven't looked at the go sources
but hopefully this can be worked around easily.
It resolves to a bunch of #ifdefs, #undefs,
On Fri, Jul 22, 2011 at 08:41:49AM -0400, erik quanstrom wrote:
On Fri Jul 22 01:37:35 EDT 2011, arn...@skeeve.com wrote:
Does Go use things that are bison-specific? If not, maybe Berkeley Yacc
(there are various versions around) would be easier to port.
if it does, that is something new.
On Fri, Jul 22, 2011 at 11:13:26AM -0400, erik quanstrom wrote:
why do you think changes to the grammar would depend on bison?
Is that what I said? I meant that the yacc modules were almost certainly
altered considerably since the introduction of new language features.
I don't have the
On Fri, Jul 22, 2011 at 08:39:56AM -0700, Bakul Shah wrote:
Is your goal to a) have the standard go distribution build on plan9
with no changes or b) do a minimal infrastructure to make future ports
easy or c) do a one time port?
The crucial feature is that any changes to the Go
On Fri, Jul 22, 2011 at 05:35:24PM +0100, Steve Simon wrote:
My understanding is that bison can be convinced to output some static
tables which the Go authors munge into some C source (with awk).
These tables allow the Go parser to generate more useful and
accurate error messages.
That
On Fri, Jul 22, 2011 at 07:53:30PM +0200, Lucio De Re wrote:
That suggests that porting Bison is a must as anything else will
not meet the criterion of being included in the Go distribution.
Bootstrapping Bison seems to be my main obstacle (it relies on Bison
features, not least the very same
On Fri, Jul 22, 2011 at 01:53:41PM -0400, erik quanstrom wrote:
can you give am example where // comments with ' cause
trouble. i can't replicate.
I don't have an example ready at hand.
Russ correctly points out that the problem lies with cpp and not with 8c,
while careful inspection of the
On Fri, Jul 22, 2011 at 02:20:37PM -0400, erik quanstrom wrote:
Russ correctly points out that the problem lies with cpp and not with 8c,
while careful inspection of the yacc sources including your correction to
accept // does not reveal any way in which yacc can be held responsible.
On Fri, Jul 22, 2011 at 02:22:54PM -0400, comeauat9f...@gmail.com wrote:
On Jul 22, 2011, at 1:53 PM, erik quanstrom quans...@labs.coraid.com wrote:
can you give am example where // comments with ' cause
trouble. i can't replicate.
My guess is that he is not referring to 8c et al but
On Fri, Jul 22, 2011 at 07:30:47PM +0100, Ethan Grammatikidis wrote:
On Fri, 22 Jul 2011 17:35:24 +0100
Steve Simon st...@quintile.net wrote:
My understanding is that bison can be convinced to output some static
tables which the Go authors munge into some C source (with awk).
I wonder
On Fri, Jul 22, 2011 at 11:32:43AM -0700, Skip Tavakkolian wrote:
I really would like an educated answer to this -- if anyone has done
the deep thinking: Can I assume that I can use linuxemu -- as a close
enough approximation of linux -- to run the Go build (i.e. all.bash)?
Or, can anyone
On Fri, Jul 22, 2011 at 11:55:45AM -0700, Bakul Shah wrote:
On Fri, 22 Jul 2011 14:48:44 EDT comeauat9f...@gmail.com
comeauat9f...@gmail.com wrote:
On Jul 22, 2011, at 2:38 PM, Bakul Shah ba...@bitblocks.com wrote:
On Fri, 22 Jul 2011 13:53:41 EDT erik quanstrom
I've been trying to port (GNU) bison to Plan 9 to make it easier
to get the Go release to compile under the Plan 9 native toolchain.
I needed to take a breather yesterday, it is just oh so frustrating!
Has anyone got bison ported yet? I suppose I could try linuxemu (hadn't
thought of that!) in
On Thu, Jul 14, 2011 at 03:59:08PM -0300, stephano zanzin wrote:
Great! I just came to the list today looking for some content about Go in
p9, I'll code many stuff in Go and was wondering if it was ported. Count me
in for testing and would be much appreciated if you highlight what have been
On Tue, Jul 12, 2011 at 08:35:26PM +0200, Francisco J Ballesteros wrote:
If you could put just a tgz at sources I'm willing to test it,
even for updates, I could just unpack the tgz again and rebuild the thing.
although I don't have much spare time these days and it's likely
I wont be able to
On Wed, Jul 13, 2011 at 08:31:58PM +0200, Lucio De Re wrote:
There are many inconsistencies I am vaguely aware of, feel free to remind
me and make suggestion on how to improve them.
One problem is the lack of execute permissions, you may have to fix these.
Lucio.
On Tue, Jul 12, 2011 at 08:59:22AM +0300, Pavel Zholkover wrote:
I'm not sure about gcc, but the go toolchain can produce quite well working
Plan 9 binaries.
Taru also has the go toolchain running native in itself after some
modifications.
Is there a link to this, please?
I want to take
On Wed, Jun 29, 2011 at 03:34:32PM -0700, Lyndon Nerenberg wrote:
I'd be curious to see what you came up with.
It was the emulation of a handset, on screen, driving an interface
adapter that communicated digitally with a small PABX. I can post the
ancient Inferno code as is on my web site,
On Sat, Jun 25, 2011 at 02:10:23PM -0700, Lyndon Nerenberg wrote:
Anyone working on or have a simple SIP router/proxy for Plan9? As
of today I will no longer waste days of my life dealing with the
abomination that is Asterisk.
I'd love to hear of such a success story.
Me, I'd have used
On Fri, May 27, 2011 at 08:21:14AM -0400, erik quanstrom wrote:
do you propose being able to do this at any level in the fs
heirarchy, or just at the root? if not just at the root, how
is a namespace constructed?
I'm going to throw a small pebble into this pond, in case it goes
overlooked:
On Sun, May 08, 2011 at 08:27:53PM +0200, tlaro...@polynum.com wrote:
(this is
probably a barbarism, but in french sophistiqué is pejorative:
obfuscation, convoluted etc.).
In Italian in 1969, sofisticato meant adulterated. I'm not sure if
that is still the case. I think I see what you
On Thu, May 05, 2011 at 11:45:27PM -0700, errno wrote:
I'm tired of maintaining everyone's computers in my house on an ad-hoc
basis; and I think I could deploy a higher performing, more maintainable,
but overall cheaper network with Plan 9. But I can hardly expect visitors
and family to run
On Fri, May 06, 2011 at 09:07:07AM -0700, errno wrote:
But you're stuck, aren't you? As soon as, say, a browser is developed for
Plan 9 (assuming that someone could afford the resources), the standards
will change and the browser will need major surgery. Who's going to
invest in that?
On Thu, May 05, 2011 at 12:33:47PM +, Greg Comeau wrote:
* I don't know much about it, but I know a number of people
who still use dumb terminals and such and swear by lynx.
Links was ported to Plan 9 (I'm sure copies of it can be found).
The problem here would be tracking developments,
the latest proud addition, open_by_handle().
You're joking, right?!
++L
On Mon Apr 18 08:58:15 EDT 2011, lu...@proxima.alt.za wrote:
the latest proud addition, open_by_handle().
You're joking, right?!
http://lwn.net/Articles/375888/
now scheduled for 2.6.39, http://lwn.net/Articles/435215/ in
the kernel release status.
It was a rhetorical question :-)
cd /sys/src/cmd
for (d in 5?) @{cd $d mk install}
I'm not going to try that now...
I am :) Well, actually, given the /bin/ape/sh problem,
what I'm going to try to do is try to set up an alternative
9vx.OSX install from scratch, and apply the latter above instead
of the earlier
the way to do this is
cd /sys/src; objtype=arm mk mk clean
Just getting to play with this... had to do some copying of some of
the files first among other setbacks... ok, plain mk asks what to make,
and so I tried 'mk all' which is saying 5c does not exist, but
that's one of the
I have tweaked the Plan 9 native ar.h to allow for manual adjustment
around the different needs of Go and native Plan 9 toolchains, so now:
#ifndef SARNAME
#define SARNAME 16
#endif
SARNAME can be predefined to the 64 that Go prefers. Unfortunately,
it's a short term
PS: I still can't link an executable with the version of 8l from the
Go toolchain that I built under Plan 9, but I'm hoping to get there
soon.
It's of some consolation to me that I see exactly the same results
under Ubuntu, so that particular problem isn't in the 8l executable
created for Plan
PS: I still can't link an executable with the version of 8l from the
Go toolchain that I built under Plan 9, but I'm hoping to get there
soon.
It's of some consolation to me that I see exactly the same results
under Ubuntu, so that particular problem isn't in the 8l executable
created for
The following executables are installed into $GOROOT/bin as Plan 9
a.out binaries when you run make -k install inside src/pkg:
cgo, ebnflint, gofix, gofmt, gotest, gotype, govet, goyacc, hgpatch.
They should be directed somewhere else by setting GOBIN, there is no
need to include them in your
The new build incantation is:
cd $GOROOT/src/pkg
make clean
mkdir -p $GROOT/bin/plan9
GOOS=plan9 GOBIN=$GOROOT/bin/plan9 make -k install
I won't try this until the mmap problem you refer to is resolved, so a
question is in order: are the plan 9 tools essential to the operation
of 8l with
.../src/cmd/8a/asm.c, around line #900:
/* This null SHdr must appear before all others */
sh = newElfShdr(elfstr[ElfStrEmpty]);
My guess is that this needs to be followed by an instruction to write
out the header, which in fact does not take place.
I will not be
On Mon, Apr 04, 2011 at 10:37:30AM +0300, Pavel Zholkover wrote:
Thanks for the detailed explanation, I've added your patch to if that
is alright with you https://bitbucket.org/paulzhol/golang-plan9-
runtime-patches/
May I suggest that we identify Go executables, because they may not run
On Mon, Apr 04, 2011 at 10:18:12PM +0300, Pavel Zholkover wrote:
On Mon, Apr 4, 2011 at 8:27 PM, Lucio De Re lu...@proxima.alt.za wrote:
PS: Would anybody like to summarise for us plebs whether there is any
convergence looming between Go and Plan 9 on the x64 front? It seems
sad to miss
On Mon, Apr 04, 2011 at 07:27:28PM +0200, Lucio De Re wrote:
On Mon, Apr 04, 2011 at 10:37:30AM +0300, Pavel Zholkover wrote:
Thanks for the detailed explanation, I've added your patch to if that
is alright with you https://bitbucket.org/paulzhol/golang-plan9-
runtime-patches
On Mon, Apr 04, 2011 at 04:10:15PM -0700, ron minnich wrote:
On Mon, Apr 4, 2011 at 10:27 AM, Lucio De Re lu...@proxima.alt.za wrote:
May I suggest that we identify Go executables, because they may not run
under 9vx, as different from Plan 9 executables and adjust the Plan 9
kernel
On Tue, Apr 05, 2011 at 12:22:18AM -0400, Russ Cox wrote:
The number of people who want to run Go on Plan 9
is already small. The number of people who want to
run Go on Plan 9 on 9vx is smaller yet. At that point
why not just run Go directly?
All that Microsoft thinking (99.9%-thinking, if
On Mon, Apr 04, 2011 at 04:33:29PM -0400, erik quanstrom wrote:
[ ... ]
then you can get rid of the old definitions in /*/include/u.h
and declare a flag day. having both seems wrong to me.
you might as well just do a local hack for the go stuff at that
point.
the hard part is convincing
On Tue, Apr 05, 2011 at 01:11:35AM -0400, Russ Cox wrote:
All that Microsoft thinking (99.9%-thinking, if you find the other label
offensive) to avoid adding a minute, one-off change to the Go runtime?
It is not a minute, one-off change.
I stand corrected.
I don't know how to fix it to
On Sat, Apr 02, 2011 at 07:48:14PM -0700, Rob Pike wrote:
We'll get the Plan 9 implementation up to scratch. It's not there yet,
though. Once things look solid we'll need a volunteer to set up a
builder so we can automatically make sure the Plan 9 port stays
current.
That's code for we'll
On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
but there definately are some difficult bits. this hacked
inclusion of stdio.h is a problem on plan 9.
On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
a real solution would be one of
0 copy u.h; hack to taste
1 add the hacks to the real u.h
2 come to a concensus with go about what the defined-bit-width
types should be called. change both plan 9 and go to conform.
i'd
On Sun, Apr 03, 2011 at 07:49:06PM +0300, Pavel Zholkover wrote:
What about the old gcc3 port? Is it enough for bootstrapping the compilers?
On Apr 3, 2011 7:28 PM, Skip Tavakkolian skip.tavakkol...@gmail.com
wrote:
You'd perpetuate an alien binary format, which sounds like a bad idea
to me.
On Sun, Apr 03, 2011 at 01:43:53PM -0400, Devon H. O'Dell wrote:
Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...
That would be great. I don't even pretend to keep track of what the GCC
group does, I guess I owe you thanks for correcting me. If that's how one
goes
On Sun, Apr 03, 2011 at 11:20:25AM -0700, Rob Pike wrote:
I'm not sure I follow. The 6c and 6g compilers in the Go distribution
are compiled with the local compiler, such as gcc on Linux and OS X.
I don't believe it's possible they have Plan 9-specific features in
their source. I can
On Sun, Apr 03, 2011 at 07:50:20PM +0100, Steve Simon wrote:
A month or so ago I got the go compiler chain to build on plan9,
port is too grand a term, it was just fixing a few nits.
That makes a third version. I seem to remember Erik's version compiled clean
and I have to ask Steve now
On Fri, Mar 25, 2011 at 07:57:36AM -0400, erik quanstrom wrote:
for the record, you can set the path. e.g.
path=($path /some/other/directory)
the default path is (. /bin).
Probably because one doesn't want to bind . to /bin for every
. visited, not because it's a good idea.
On Fri, Mar 25, 2011 at 08:25:27AM -0400, erik quanstrom wrote:
i never could get past the fact that texbook reeks of hubris
and nih, nor forgive gnu for using info as an excuse for not
having man pages. that, and the fact that it's at least 100x
slower than troff, and the reader requires
does anything think that it's a mistake to default dma on?
I have a lot of old kit around and can't for the hell of me figure out
which drives do need and which ones don't want DMA, occasionally
losing if nothing else a lot of time and effort in repairing a bad
assumption. Having a kernel
On Mon, Mar 14, 2011 at 11:42:13AM +0100, Peter A. Cejchan wrote:
sorry, type is void *fn()
or void *fn(void) ?
You may, if I'm guessing right, have to tighten up. It's more complicated
than I can get my mind around...
Lucio.
On Wed, Mar 09, 2011 at 08:31:09AM -0500, Jacob Todd wrote:
What's your point?
Trolling?
++L
On Tue, Mar 08, 2011 at 10:24:48AM +0100, cinap_len...@gmx.de wrote:
Fish- has catched this on a Intel(r)915GM/910ML/915MS Graphics Controller
with realemu:
bad mem write c0c11
bad memory access
1d17b0 4a008800 0002 a002 9000 5108 ac007bda
7bc0
On Tue, Mar 08, 2011 at 07:21:50AM -0800, Paul Lalonde wrote:
The last time I poked at one of these self-modifying bits they were really
just jitting a blit loop, in place. Drops register pressure a little bit,
which has always been a bit of an issue in x86 land.
A bankrupt CPU architecture.
it may be that instruction sets aren't very important any longer.
I wish I had the persistence to respond to this gem in detail.
What is important, in my opinion, is progress in some undefinable,
but recognisable sense. Faster and faster isn't it and it does seem
to set higher and higher entry
so it seems clear that constants are treated as if unsigned, regardless,
but variables are not?
the really wierd bit is that the 1 in 1i suddenly becomes signed,
even though other constants are treated as if unsigned, and i is
unsigned.
I would not hesitate to call that a bug.
I would
On Mon, Mar 07, 2011 at 11:39:10AM +0100, cinap_len...@gmx.de wrote:
the /dev/realmode intraface was not documented, but it is very simple.
Thank you for explaining this.
/dev/realmodemem is just an image of the first megabyte of
physical memory that is addressable from 16 bit realmode.
On Mon, Mar 07, 2011 at 07:23:36AM -0500, erik quanstrom wrote:
in /dev/realmode, you write a struct Ureg (from /386/include/ureg.h)
(in x86 machine byte order?) containing the register contents and the
interrupt number of the bios call you want to make.
yes. you should use libmach to
On Mon, Mar 07, 2011 at 09:19:58AM -0500, Russ Cox wrote:
huh? what does libmach (which takes apart executables)
have to do with any of this?
Did I get the wrong impression when I perceived libmach, as released
with GoLang - cause that's where I looked - seemingly quite capable of
301 - 400 of 468 matches
Mail list logo
