<jhj>
waddlesplash: The guy who originally started the project and wrote the first bits of the CPU code, Harry Reed, passed away recently. One of the other coders on the project, Charles, did the hercluean effort and wrote the vast majority of the rest of the code.
<waddlesplash>
RIP
<jhj>
Indeed.
<jhj>
The CPU code is the part I'm least comfortable with and don't have a full understanding of all the details, but I've touched at least 60% of it. We've improved the performance by about 60% over the past 2-3 years.
AlaskanEmi has joined #haiku
<jhj>
But that's been by profiling individual CPU functionality and makign improvments to it, but I've not really dared to make fundamental changes to the way the CPU functionally works.
<jhj>
And where the manuals say how something was implemented, the simulator implements it the same way, even when doing so in software doesn't make a lot of sense where it would in hardware.
<jhj>
which is nice to have the hardware manuals line up with the software implementation
<jhj>
waddlesplash: also I just checked and on 32-bit platforms, there isn't any int128.
<waddlesplash>
hm, ok
AlaskanEmily3 has quit [Ping timeout: 480 seconds]
<jhj>
waddlesplash: Also, Oracle Studio C/C++ doesn't have an int128 type, and IBM's AIX XL C/C++ (and Open XL C/C++) don't support int128 in 16.1 through 17.1.1
<jhj>
IBM added support for it in the 17.1.2 version of their compiler.
<jhj>
(16.1, 17.1.1, and 17.1.2 are all currently supported versions.) This is the crazy sort of stuff that you need to care about when you support all these crazy systems :)
<jhj>
waddlesplash: Clang had ExtInt, and now C23 has BitInt, which lets you specify bit-exact types like BitInt(72) and BitInt(36) which would be so much nicer and cleaner for our code.
<waddlesplash>
interesting
<jhj>
We have weird stuff like 42-bit pointer registers and 288-bit control registers.
<jhj>
It would make the code so much cleaner if that existed back in the day.
<jhj>
Clang apparantly lets you make a 8388608-bit type.
<jhj>
GCC only goes to 65535.
<Skipp_OSX>
not to mention my Sterling approximation sigh
<Skipp_OSX>
(arithmetic on larger than 64-bit ints in DeskCalc for large factorials)
<waddlesplash>
jhj: well, you could've used C++ and defined these as classes :P
<jhj>
Having 256-bit and 512-bit and similar types would be great for hashes and crypto and stuff
<jhj>
waddlesplash: Well, maybe, but I am more of a C person.
<waddlesplash>
I'm trying it out now on an optimized DPS8 build
<waddlesplash>
gives a nice display for per-line CPU time usage
<jhj>
I also did once make this project compile with a C++ compiler, but it was terrible.
<jhj>
The reason being is that we use setjmp/longjmp to do our own exceptions for fault and interrupt handling
<waddlesplash>
sounds slow
<jhj>
And on C++, that involves doing expensive unwinding stuff and calling implicit/auto destructors and whatever on each call.
<waddlesplash>
-fno-exceptions
<jhj>
waddlesplash: We did benchmarks of our longjmp stuff vs. goto, and it's barely more overhead in fact.
<waddlesplash>
hm, ok
<jhj>
As long as the signal mask isn't saved and restored on each call.
<jhj>
And where that happens by default, like on the BSDs, we use _setjmp/_longjmp that don't.
<jhj>
waddlesplash: I believe that fno-exceptions doesn't inhibit the constructor/destructor behaviors on longjmp and many core C++ things depend on that.
<jhj>
I might be wrong :)
<waddlesplash>
I think if you call raw longjmp it won't call C++ things?
<jhj>
it would indeed break nice C++ stuff though so we couldn;t use smart pointers and other nicities
<waddlesplash>
solution: use C++ exceptions insteadof SJLJ
<waddlesplash>
they should be pretty fast these days
<Skipp_OSX>
but C++ exceptions are terrible
<Skipp_OSX>
inevitable, but terrible
edouardlicn has quit []
<jhj>
I don't know C++ well enough to have strong opinions on anything.
<Skipp_OSX>
out-of-band control flow is difficult to debug
<jhj>
I'm one of those silly elderly C programmers that the hip kids make fun of.
<Skipp_OSX>
Multiple-return methods with second error param is really nice but C++ even 20 doesn't have those
emily__ has joined #haiku
<Skipp_OSX>
multiple return values
<jhj>
I actually like Go's error handling, since we are speaking of that.
<jhj>
Nobody else does it seems, but returning multiple things directly is handy.
<milek7>
well, you could return tuple
<Skipp_OSX>
yeah same idea
<jhj>
ksh93 supports that, you can return a compound
<Skipp_OSX>
yeah it's nice
<Skipp_OSX>
return value in first parameter, error in second, downstream can check for 2nd parameter before using first
<jhj>
ksh93 (and zsh, but not as nice as ksh93 does it) also support floating point math.
<Skipp_OSX>
or not, take value anyway
<jhj>
It's a shame that this doesn't exist sanely in any POSIX shell, and everyones favorite bash doesn't do floating point either.
AlaskanEmi has quit [Ping timeout: 480 seconds]
<jhj>
milek7: Hey, your suggestion passes diagnostics and gets +6% on my machine.
<jhj>
I'll credit you for finding that in the eventual commit if you'd like.
<jhj>
waddlesplash: I'm going to have to take a break from this for a bit.
<jhj>
But I'm going to experiment with passing cpup as the last argument as well
<jhj>
and compare the two
<waddlesplash>
I don't know why that'd make a big difference but ok
<jhj>
I wish there was some automated way to refactor this.
<waddlesplash>
ultimately it probably makes sense to pass it as the first argument anyway
<waddlesplash>
on x86_64 there will be zero difference
<waddlesplash>
and with LTO/PGO there will be even less
<waddlesplash>
if passing it in as first vs last
<jhj>
Yeah, tons of registers available anyway.
<waddlesplash>
so I don't think it makes sense to spend a ton of time refactoring the patch for that
<jhj>
my concerns are probably obsoleted in the 90s
<jhj>
I mean, we just changed our standards to allow C11 in the project with this release :)
<milek7>
jhj: it's really minor thing, but sure :)
<jhj>
np
<jhj>
It's amazing how much the compiler inlines stuff these days on systems like x86_64.
<jhj>
waddlesplash: we have some MATRIX code leftover from back in the day, which is sort of a cheap profiler that counts instruction use frequency, and we used that to reorder the case statements in dps8_instr
<jhj>
And it was a small but real improvement in older compilers, but these days, it doesn't make that much of a difference.
<milek7>
computed goto is sometimes useful for that
emily__ has quit [Remote host closed the connection]
emily__ has joined #haiku
AlaskanEmi has joined #haiku
<milek7>
and fast interpreters can be done by avoiding stack frames and tail calling everywhere (llvm musttail)
<milek7>
but that's probably hard to do for cpu that much CISCy
<jhj>
a JIT is something I want to look into one day.
emily__ has quit [Ping timeout: 480 seconds]
<jhj>
and yes, the CPU is super-CISC. There are string manipulation functions that do things like compare entire strings or convert bases
<jhj>
or do decimal number formatting in a single instruction
<jhj>
those single instructions map directly to COBOL or PL/I 'PIC' and 'INDEX' statements
<jhj>
milek7: on the later 80s and 90s iterations of these 6000 processors, those instructions were handled by microprocessors.
<jhj>
those EIS/"business" instructions were something like 20 or 25 full boards of the CPU cabinet
<jhj>
in the late 70s / early 80s hardware
<jhj>
there were cheaper variants early on that didn't have them
AlaskanEmi has quit [Ping timeout: 480 seconds]
<milek7>
how fast was the real hardware?
<jhj>
milek7: The last hardware which had the appending unit, which is the "MMU" that Multics requires, was about 1.8 MIPS.
<jhj>
milek7: By the 90s, the top-end 6000-series CPU machine was advertised at 700 MIPS
<jhj>
With 8 CPUs
<jhj>
The single CPU one of those was advertised at 110 MIPS
<jhj>
But that's without the appending unit which is really heavy.
<jhj>
milek7: but anyway, we run Multics now much faster than the fastest hardware ever ran Multics.
<jhj>
The current machines also use emulation. One day I should make an absolute mode benchmark and see if I can find someone to run it on one. :)
<jhj>
This 9000 series was the last ones that had their own custom processors.
<jhj>
The Bull NovaScale system came out in 2005 I think, which was when they switched to commercial CPUs, and running 36-bit code in emulation.
<jhj>
There is a GCOS-7 series of systems, which are 64-bit, which derive from the 32-bit DPS-7 line, and for those, the GCOS code runs mostly natively these days.
<jhj>
It's my understanding that the systems use virtualization and essentially every GCOS-7 program runs in its own virtual machine.
<jhj>
Those systems were related but distinct from the 36-bit line however.
<jhj>
The 36-bit machines were "large systems" and the 32-bit machines were "medium systems" and the 18-bit and 16-bit machines were "satellite" or "departmental" minicomputers.
<jhj>
Each one of them had a GCOS OS, all of which were distinct source code, but lookalike operations for users and very similar API for programmers
<jhj>
CP-6 and Multics only ran on the 36-bit "large systems" line.
<milek7>
so in 1991 there were still developing 36-bit system?
<jhj>
At the end of the 80s / early 90s they decided it didn't make sense to support three incompatible flagship operating systems... outside consultants recommended they pick Multics, but politics resulting in GCOS winning, so GCOS lives on.
<jhj>
milek7: Yes, I think the last was the DPS-9000 in 1993 or 1994 in fact.
ChaiTRex has quit [Remote host closed the connection]
ChaiTRex has joined #haiku
Begasus has joined #haiku
<Begasus>
g'morning peeps
OscarL has joined #haiku
<OscarL>
morning Begasus.
<coolcoder613>
Hello OscarL, Begasus
<Begasus>
Hi OscarL coolcoder613!
<OscarL>
hello coolcoder613 :-)
<Begasus>
fsckn waiting for ...
<coolcoder613>
I got a PS/2 mouse and installed BeOS on my Deskpro, but it doesn't have graphics drivers
<coolcoder613>
So I'm stuck on grayscale 640x480
<OscarL>
Begasus: taking a look at autoreconf... IMO, it is missing quite a few deps, as docs say: "‘autoreconf’ runs ‘autoconf’, ‘autoheader’, ‘aclocal’, ‘automake’,
<OscarL>
‘libtoolize’, ‘intltoolize’, ‘gtkdocize’, and ‘autopoint’ (when
<OscarL>
appropriate)"... and none of that is on its REQUIRES :-/
<OscarL>
then I started looing at "ir autoreconf" (to see where we could cleanup depeencies if autorecof was fixed)...
<Begasus>
have fun with that one OscarL, tried to do some cleaning/fixing up a while ago, didn't go to well iirc
<OscarL>
found things like "libidn", that requires aclocal/automake/autoreconf/etc... and doesn't calls any of that, just ./configure :-/
<Begasus>
most of those are not in use by configure
<Begasus>
only needed when you use configure.ad/in
<Begasus>
ad/ac*
<OscarL>
right, that's why the libidn recipe got me... "WTF do you want all of this for?" :-D
<Begasus>
too early, haven't had any coffee yet :)
<Begasus>
found a way (with help from upstream) to get the breeze-icons package build on 32bit, first need to do a few more build runs to be sure :)
<OscarL>
coolcoder613: In 2000... I installed BeOS R5 on an AMD-K5 with a Trident TGUI9440 that wasn't supported... (stuck on grayscale too)...
<OscarL>
but there's a trick...
<OscarL>
boot into DOS... install UniVBE TSR (that adds VESA 2.0 support), boot BeOS from DOS, via loadbeos.com
<OscarL>
Not ideal.. but better than the alternative.
<Begasus>
whoot Trident, iirc that was the first hardware peice I ever bought for a PC :D
walkingdisaster has joined #haiku
<OscarL>
if you configure things well enough, you can automate the whole thing, and only use DOS as an interim step into booting BeOS.
<OscarL>
coolcoder613: just in case... the loadbeos.com I mention comes from the Windows version of the BeOS R5 PE installer.
<coolcoder613>
Or I could try get a PCI graphics card
<OscarL>
this trident card I mention *was* PCI... it just was VESA 1.4 :-D
<OscarL>
BeOS VESA driver needs 2.0 minimum.
<Begasus>
reboot and biab (have to take one of the kids to work)
Begasus has quit [Quit: Vision[]: i've been blurred!]
<arraybolt3>
DOS-as-bootloader both sounds insane and makes perfect sense.
Begasus has joined #haiku
<OscarL>
arraybolt3: DOS was grub before grub :-P
<Begasus>
re
<coolcoder613>
That's how BeOS PE worked in Windows 9x
<coolcoder613>
The bootloader could run from Windows, replacing it with BeOS
<OscarL>
coolcoder613: BeOS R5 PE "for linux" did something similar.
<coolcoder613>
How?
<OscarL>
don't recall what it used, but it was definitively a thing.
<OscarL>
https://archiveos.org/beos/ seems to have "BeOS 4 Linux 41MB.tar.gz" as well as the windows version.
<OscarL>
Mmm, tar.gz gives "/boot/system/bin/tar: Unexpected EOF in archive"
<OscarL>
ah, it had a floppy.img :-)
<OscarL>
"To boot the image.be Personal Edition partition image, place it at in a directory called 'beos' at any root point on a ext2 partition. ex, /beos/image.be, or if you have /home on a seperate partition,
<OscarL>
it could be placed at /home/beos/image.be"
<OscarL>
then you had to boot from floppy, so... not really "chain-loading".
<Begasus>
will wait for breeze_icons to finish before push the other KF6 frameworks, glad to get this up to speed :)
<Begasus>
whoot, it's almost done :D
<OscarL>
Welp, Haiku beta5 TC0 also doesn't boots on this damned netbook (Atom N2600 based, no screen). In UEFI mode, tried to boot from USB pendrive, boot loader attempts to boot an older nigthly from the HDD (doesn't sees the one on the USB drive).
<OscarL>
on Legacy/BIOS mode, finds the USB drive alright, reaches the rocket icon, and then freezes (have to power off). Tried all boot options. No go.
<botifico>
[haikuports/haikuports] Begasus f7d9c07 - kdoctools6, bump version (#10942)
<OscarL>
second "miniPCIe" port on that netbook only seems to have USB interface (for a TV/FM tuner). Was hoping to be able to use two wifi cards instead :-)
<OscarL>
Guess I'll just use it as a slightly faster "server" than the other netbook I also can't run Haiku on (Atom N455).
<botifico>
[haikuports/haikuports] Begasus e2a9c77 - kitemviews6, bump version (#10947)
<OscarL-N2600>
yeah, have to hit some keys twice or more, but at least they are there (the other netbook had actual missing keys, and lots of others unresponsive)
<OscarL-N2600>
mmm, DEL key not working, no wonder CTRL+ALT+DEL didn't worked :-D
erysdren has quit [Quit: Konversation terminated!]
<OscarL-N2600>
pkgman update wants me to update to hrev58021 :-/
* OscarL-N2600
changes repos to r1beta5
<dovsienko>
milek7: this is what a 16-bit CPU looks like if built from discrete elements: https://www.megaprocessor.com/
diver has joined #haiku
diver1 has quit [Read error: Connection reset by peer]
<botifico>
[haikuports/haikuports] Begasus 7adcfae - kcrash6, bump version (#10949)
<dovsienko>
OscarL-N2600: make sure this laptop runs from an SSD
<OscarL-N2600>
wifi seems to glitcht a bit, but meh.... ethernet for life.
jmairboeck has joined #haiku
<dovsienko>
I would also be tempting to max the RAM out because N2600 is 64-bit and won't be limited by 4GB, but with some old hardware the thing is that when it has been running not at the highest spec, and then you try to upgrade it, it fails
<dovsienko>
(unless the RAM is soldered to the board)
<OscarL-N2600>
dovsienko: no money for SSDs :-D (Argentine's economic life, heh).
<OscarL-N2600>
atom n2600 limited to 2 GB max ram.
<OscarL-N2600>
sadly
<OscarL-N2600>
has dimm slot, but has 2GB already.
<dovsienko>
is it SATA at least?
<OscarL-N2600>
yup.
<OscarL-N2600>
I'm pretty used to slow hardware (best machine is a Phenom II X4), so this actually working at all (at last) is already incredible :-D
<OscarL-N2600>
ssh using "/packages/openssh-9.8p1-2/.self/data/openssh/empty:/bin/true" as shell (in passwd file) seems wrong
<Begasus>
fix it? :P
<OscarL-N2600>
not while using tis keyboard
<OscarL-N2600>
+h
<Begasus>
heh
<Begasus>
I'm glad nextcloud-client is fixed, can share recipes/patches easy now between the laptops, saves typos :D
<OscarL-N2600>
ah, missed the ":". /bin/true as shell is ok, I guess. the weird thing is the dir for its "home"
<OscarL-N2600>
using paths with package versions in them on setting files can be a tripwire.
<OscarL-N2600>
(darn bash-completions getting broken on package update, for example).
<Begasus>
for my use it's still ok :)
<OscarL>
yeah, using the netbook via ssh (with this working keyboard)... much better :-D
<Begasus>
geek! :P
<OscarL>
I'm really happy this is working! /me hopes it is not just a fluke :-D
<Begasus>
crossing my fingers for you :)
<OscarL>
+1
<OscarL>
once I setup mDNSResponder (so I can forget about changing IPs), this will be sweeet!
<OscarL>
Will probably do that after getting some sleep, thou... 7 AM already here, yikes.
<Begasus>
jikes he says
<Begasus>
it's the time most people wake up :P
<OscarL>
most *sane* people.
<Begasus>
or at least had their first coffee
<Begasus>
heh
diver has quit [Read error: Connection reset by peer]
<Begasus>
bugger ...
<OscarL>
starting Midnight Commander with "mc -u" is significantly faster than plain "mc". Maybe there's a way to make it use something ligther than bash as sub-shell.
<phschafft>
what does -u do?
<OscarL>
disables sub-shell support.
<OscarL>
you still get the command line at the bottom, but it is not longer your usual shell, and CTRL+O doesn't works.
<dovsienko>
in the old times when Internet was slow, I regularly had to use "mc -sb", and when your terminal settings were not good for whatever reason, it was "mc -a" to make it completely low-end
<OscarL>
remember using -a, yes. still pretty slow start up here unless I add -u still :-D
<phschafft>
hm, I see.
<OscarL>
order matter, hehe, "mc -a -u" slow, "mc -u -a" fast, heh.