Click Here
home features news forums classifieds faqs links search
5740 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
Home
Features
News
Forums
Classifieds
Links
Downloads
Extras
OS4 Zone
IRC Network
AmigaWorld Radio
Newsfeed
Top Members
Amiga Dealers
Information
About Us
FAQs
Advertise
Polls
Terms of Service
Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
21 crawler(s) on-line.
 16 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 matthey:  13 mins ago
 gonegahgah:  40 mins ago
 MEGA_RJ_MICAL:  50 mins ago
 annasolano:  1 hr 10 mins ago
 K-L:  1 hr 33 mins ago
 WeiXing3D:  1 hr 42 mins ago
 eliyahu:  1 hr 50 mins ago
 MEGA.RJ.MICAL:  2 hrs 22 mins ago
 cc3d:  2 hrs 33 mins ago
 DiscreetFX:  2 hrs 39 mins ago

/  Forum Index
   /  Amiga General Chat
      /  Amiga Nowhere
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 Next Page )
PosterThread
amigang 
Re: Amiga Nowhere
Posted on 11-May-2020 10:42:45
#21 ]
Super Member
Joined: 12-Jan-2005
Posts: 1487
From: Cheshire, England

@NutsAboutAmiga

Quote:
The UAE argument form a programming perspective is bad, because it does not give direct access to things like 3D, video decompression, file system, memory management, its also pretty bad because it has to use JIT, and it does not support more then 1 cpu core, the problem is thats a hardware platform, not a software platform.


I think your kinda of missing my point, lets say you want to make a new game, but retro style think sonic mania (that was a huge success and in way could of most like be made to run on a Mega drive (maybe)). or it could be a simple game like Tomas was Alone / Vvvvvvv all have been commercial successful games, they could of been made on the Amiga, then using UAE you could port it to every platform out there, now is this a clever or ideal way of doing it, no, but it is a way of doing it. If you want to make a game / app say beyond what an A1200 could do then, no this is not the way to do it, but for simple games it could be a viable way of doing it.

I remember looking for a good Spectrum emulator for the PC years ago, found a few but had just a ton of issue with controllers, getting the old Kempston control to work, for what ever reason I just was not able to get it to work. then I remembered that I had brilliant and easy speccy emulator on my Amiga, and yes this might seem mad, but to this day I still use my old Amiga setup emulated on my PC to run an emulator with in a emulator to play speccy games on, thanks to this, once I get my Amiga setup working on UAE, which I have on my Phone, PC, AmigaONE X1000 and Laptop, not only do I know I got a great Amiga environment to play with, I got my Spectrum setup too

Last edited by amigang on 11-May-2020 at 10:52 AM.

_________________
AmigaNG, YouTube, LeaveReality Studio

 Status: Offline
Profile     Report this post  
Cool_amigaN 
Re: Amiga Nowhere
Posted on 11-May-2020 11:16:04
#22 ]
Super Member
Joined: 6-Oct-2006
Posts: 1192
From: Athens/Greece

I recently did a tribute article for the latest issue of RetroPlanet, located here about AA/AmigaDE. Reflecting almost two decades back with today's knowledge, I think one thing must be granted to Bill McEwen; he was spot on from a business perspective. His words on Amiga Active once made me lose hope about the Amiga (when explaining Amiga Anywhere and the market he was targeting) but his vision of having same binaries (or even a whole OS underneath the host), executed across different devices (and especially mobile ones) was clearly 100% correct. I don't know how many people remember how he was very persistent when he spoke about mobiles (phones/pdas). Personally, I never anticipated the market's rapid transformation and explosion it underwent at the end of the century's first decade. But he was stating it over and over again at least 10 years before it happened!

Also, back then there was no Java on mobile (my first Moto shipped Q1 2004 with a J' derivative) and companies were investing / developing in proprietary OSes. However he shouldn't focus on selling it, to end users. TAO Elite was never a platform to build a community. Instead he should hire a small team to develop some apps for a specific mobile vendor and make a demo out of it. Show the extra values of the platform. Perhaps he was completely out of cash though, who knows? Had him stroke a deal with a major mobile vendor back then, A. Inc. would have float a lot longer. Still the inevitable (Android / iOS) would have caught him.

All in all: his budget was tight, rebranding an innovative idea (TAO) and targeting a market which a couple of years afterwards faced a vast growth perhaps would have gained him money and a small footprint among giants but he was doomed to fail against Apple and Google (hell, even Microsoft quit!).

Selling the party packs to Amigans was lame, imo.

_________________

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Amiga Nowhere
Posted on 11-May-2020 11:55:35
#23 ]
Elite Member
Joined: 9-Jun-2004
Posts: 11331
From: Norway

@amigang

Then you go for hardware virtualization and get max out of your CPU, instead turning your 5GHz core into 200-300Mhz 680x0 cpu. So what if you emulate 3 x 680x0 at 300Mhz, the OS does not support it, yes you do like AMP in your game, sure you can but way. you can't run it on a classic Amiga system, now that you modfied your game only work on 3 x 680x0 CPU's

I guess it can be interesting for emulating some kind of old UNIX 680x0 server, I think SUN1 was a signal CPU machine. If remember correct most first UNIX server did not come with graphic cards, but only terminal, so maybe not impossible make emulator, maybe emulators like this already exist.

Last edited by NutsAboutAmiga on 11-May-2020 at 08:37 PM.
Last edited by NutsAboutAmiga on 11-May-2020 at 12:43 PM.
Last edited by NutsAboutAmiga on 11-May-2020 at 12:41 PM.
Last edited by NutsAboutAmiga on 11-May-2020 at 11:57 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
gonegahgah 
Re: Amiga Nowhere
Posted on 11-May-2020 13:44:32
#24 ]
Regular Member
Joined: 5-Dec-2008
Posts: 124
From: Australia

@Thomas

I didn't know there was something similar in Android.
I've never used the Java side of things really either.

Elate supposedly supports either endedness but I've never tested it.
This might be relevant to part of my code that loads non-aligned data.
Supposedly some CPUs organise their pointer and integer byte formats differently?
(According to the docs).
But intel pointers and integers are internally identical.
So I can't test if my loading works on CPUs where they aren't the same.
I've written it hopefully in a way that will work but maybe that will never be tested?

The system also has only 32bit pointers.
I'm wondering if it is possible to make a code system able to auto work as either 32bit or 64bit?

I had kind of expected Amiga to do a version that ran on Amigas as well.
But as you say, they never did. Maybe there were too many technical hurdles?
The system did piggy back off the host OS to a degree.

I may still have the original discs somewhere...

 Status: Offline
Profile     Report this post  
ppcamiga1 
Re: Amiga Nowhere
Posted on 11-May-2020 18:31:44
#25 ]
Regular Member
Joined: 23-Aug-2015
Posts: 183
From: Unknown

AInc provide something that has nothing common with Amiga but still exotic and with all Amiga flaws.
So they loose.
AInc should do what Apple really do.
Custom gui and graphics on top of unix.

Last edited by ppcamiga1 on 11-May-2020 at 06:32 PM.

 Status: Offline
Profile     Report this post  
matthey 
Re: Amiga Nowhere
Posted on 14-May-2020 20:17:05
#26 ]
Cult Member
Joined: 14-Mar-2007
Posts: 677
From: Kansas

Quote:

gonegahgah wrote:
One thing I especially like is that functions can return multiple results.
I can remember having to pass structures in C which I find extremely ugly.
Not sure how that has advanced in this day and age or if it is still a problem?


With a few C99 features like variadic macros, it is possible to return multiple values.

https://github.com/segeljakt/macro-magic/tree/master/multitype

This may be convenient but usually generates less efficient code and may avoid type safety. It would be more efficient to return multiple variables in scratch registers but it would require more work to make it portable (CPU specific adaptions required).

Quote:

gonegahgah wrote:
Elate supposedly supports either endedness but I've never tested it.
This might be relevant to part of my code that loads non-aligned data.


Endian problems affect aligned data too. Any load or store of more than a byte potentially needs to have the endianess of the data changed. Some CPUs will cause exceptions on any non-naturally aligned data (the OS or Elate may be able to catch the exception and correct it with a significant performance hit). Some PPC CPUs would handle big endian mis-alignment in hardware but not so for little endian. All this needs to be clearly explained or there will be problems. Accessing all data in bytes gets around all endianess and alignment problems but is slow and performance is the key for run anywhere solutions.

Quote:

Supposedly some CPUs organise their pointer and integer byte formats differently?
(According to the docs).
But intel pointers and integers are internally identical.
So I can't test if my loading works on CPUs where they aren't the same.
I've written it hopefully in a way that will work but maybe that will never be tested?


Most non-byte addressable CPUs are very old and esoteric. The first Alpha CPU did not have 8 or 16 bit data accesses and would ignore the least significant bits of mis-aligned addresses (all accesses need to be naturally aligned). The address is still delineated in bytes which can be held by an integer. This can be assumed for practically all modern general purpose CPUs. The handling of pointers compared to integers can be different though. The 68k uses data registers for integers and address registers for pointers. Some CPUs treat addresses like signed and/or unsigned integers and not always consistently one way. This has caused problems with using more than 2 GiB of address space on 32 bit CPUs.

Quote:

The system also has only 32bit pointers.
I'm wondering if it is possible to make a code system able to auto work as either 32bit or 64bit?


It is usually easier to make 64 bit code work in 32 bit mode than adapt 32 bit code to work in 64 bit mode. Many 64 bit CPUs (most PPC & x86_64 CPUs) can operate in either a 64 or 32 bit mode (selected at boot) and assume you will compile the OS and all software for that environment. Some CPUs allow simultaneous modes to be used, including 32 bit modes, like many ARM CPUs which retains backward software compatibility.

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Amiga Nowhere
Posted on 14-May-2020 21:18:38
#27 ]
Elite Member
Joined: 9-Jun-2004
Posts: 11331
From: Norway

@matthey

The c compiler handles structure of different data, by adding padding unless you tell GCC its packed structure, in that case, the CPU just have deal with misalignment and the performance hit.

when comes to some thing that is in sate that not native assembler and not high-level C code, you can do relatively quick compilation to machine code. Just before runtime, many of these issues can be solved just before runtime, instead of having precompiled binary. (Not talking about JIT.)

Many of PowerPC cpus does support little endian, this are called reverse endian instructions. But it depends on the CPU ISA, different PowerPC isa contain different instructions, so it actually better if it was not fully compiled because you insert workarounds for ISAs that do not have some instruction, like fsel or isel or some other not so common instructions, hell some ISAs have totally different FPU instructions. And some ISAs might have one or two buggy instructions should be avoided.

Anyway, it be hell of job to keep the compiler up to date for all types of CPUs. and I guess this where bugger problem is.

Interpreter are easier but are slower, however token be optimized for optimal execution flow, that give huge befits over none optimized token organized more human readable pattern.

Last edited by NutsAboutAmiga on 14-May-2020 at 09:26 PM.
Last edited by NutsAboutAmiga on 14-May-2020 at 09:23 PM.
Last edited by NutsAboutAmiga on 14-May-2020 at 09:21 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
tygre 
Re: Amiga Nowhere
Posted on 15-May-2020 0:27:39
#28 ]
Regular Member
Joined: 23-Mar-2011
Posts: 202
From: Montreal, QC, Canada

@Cool_amigaN

Thank you! I totally agree with your points: at the time (again!) AmigaAnywhere/DE was very innovative and could have achieved greatness

Cheers!

_________________
Tygre
Scientific Progress Goes Boing!

 Status: Offline
Profile     Report this post  
matthey 
Re: Amiga Nowhere
Posted on 15-May-2020 21:26:36
#29 ]
Cult Member
Joined: 14-Mar-2007
Posts: 677
From: Kansas

Quote:

NutsAboutAmiga wrote:
The c compiler handles structure of different data, by adding padding unless you tell GCC its packed structure, in that case, the CPU just have deal with misalignment and the performance hit.


Right. By default, C compilers use padding to align data for best performance on the target CPU architecture as defined in the ABI. This auto alignment works well until the real world happens with casts, unions, compressed data, old data, etc. For example, the AmigaOS can't be used on PPC without turning the default structure alignment off.

Some CPUs handle some or all mis-aligned accesses in hardware, some give exceptions and some cause undefined behavior. Some operating systems catch mis-aligned exceptions and complete the access where possible, some give an unrecoverable error message (AmigaOS 0x80000003 guru which can occur on the 68000) and some can't or don't catch the access usually resulting in a crash with no error message.

Quote:

when comes to some thing that is in sate that not native assembler and not high-level C code, you can do relatively quick compilation to machine code. Just before runtime, many of these issues can be solved just before runtime, instead of having precompiled binary. (Not talking about JIT.)


"Relatively quick compilation" depends on the CPU performance of the target hardware. I would rather have an optimized binary ready to run than half compiled intermediate code that is going to give poor performance after waiting to compile.

Quote:

Many of PowerPC cpus does support little endian, this are called reverse endian instructions. But it depends on the CPU ISA, different PowerPC isa contain different instructions, so it actually better if it was not fully compiled because you insert workarounds for ISAs that do not have some instruction, like fsel or isel or some other not so common instructions, hell some ISAs have totally different FPU instructions. And some ISAs might have one or two buggy instructions should be avoided.


The most advanced compilers allow to specify a particular CPU as target which should optimize for that processor better than any run time compilation of intermediate code.

Quote:

Anyway, it be hell of job to keep the compiler up to date for all types of CPUs. and I guess this where bugger problem is.


Supporting AArch64 and x86_64 should be enough today. ARM support is much easier now that ARM standardized with AArch64. No more intermediate language will be necessary to support the thousands of variations of ARM hardware in the future.

Quote:

Interpreter are easier but are slower, however token be optimized for optimal execution flow, that give huge befits over none optimized token organized more human readable pattern.


A highly optimized ready to run binary offers significant benefits over intermediate code that needs compiling at run time also. Standardized hardware allows for the best performance.

 Status: Offline
Profile     Report this post  
gonegahgah 
Re: Amiga Nowhere
Posted on 16-May-2020 17:54:43
#30 ]
Regular Member
Joined: 5-Dec-2008
Posts: 124
From: Australia

@matthey

Quote:
With a few C99 features like variadic macros, it is possible to return multiple values.

https://github.com/segeljakt/macro-magic/tree/master/multitype

This may be convenient but usually generates less efficient code and may avoid type safety. It would be more efficient to return multiple variables in scratch registers but it would require more work to make it portable (CPU specific adaptions required).

That is one of the nice things about VP that multiple arguments are returned in registers rather than having to pass a structure. VP will translate and use the stack if necessary but if there are enough registers it will just use them and it's all hidden from the coder.

eg. gos GetXY,(-: iX,iY)

I can see that they are trying to partially solve the problem but even that new C99 code still looks yucky to me.

They haven't done so in the VP files but I have wondered if it wouldn't be more efficient to get cos and sine at the same time? ie. qcall lib/getcossin,(iAngle: iCos,iSin). Wouldn't that speed some things up?

Quote:
Endian problems affect aligned data too. Any load or store of more than a byte potentially needs to have the endianess of the data changed. Some CPUs will cause exceptions on any non-naturally aligned data (the OS or Elate may be able to catch the exception and correct it with a significant performance hit). Some PPC CPUs would handle big endian mis-alignment in hardware but not so for little endian. All this needs to be clearly explained or there will be problems. Accessing all data in bytes gets around all endianess and alignment problems but is slow and performance is the key for run anywhere solutions.

VP is supposed to sort out endian problems at translation time so the code runs in correct endedness.
They have commands for dealing with unaligned data such as: cpy.ni [pStorage], iValue
Their longs and doubles only unalign down to 4 byte bounderies but there are ways around that.

Quote:
Most non-byte addressable CPUs are very old and esoteric. The first Alpha CPU did not have 8 or 16 bit data accesses and would ignore the least significant bits of mis-aligned addresses (all accesses need to be naturally aligned). The address is still delineated in bytes which can be held by an integer. This can be assumed for practically all modern general purpose CPUs. The handling of pointers compared to integers can be different though. The 68k uses data registers for integers and address registers for pointers. Some CPUs treat addresses like signed and/or unsigned integers and not always consistently one way. This has caused problems with using more than 2 GiB of address space on 32 bit CPUs.

Cool, that makes a lot of sense. VP differentiates as well and you have to use commands to convert between them ie. cpy p2i pAddress, iAddress. On a modern intel CPU the p2i would just be tossed at translation time.

Quote:
It is usually easier to make 64 bit code work in 32 bit mode than adapt 32 bit code to work in 64 bit mode. Many 64 bit CPUs (most PPC & x86_64 CPUs) can operate in either a 64 or 32 bit mode (selected at boot) and assume you will compile the OS and all software for that environment. Some CPUs allow simultaneous modes to be used, including 32 bit modes, like many ARM CPUs which retains backward software compatibility.

That's an interesting thought. I was surprised that Tao were still developing in 32bit with all the 64bit CPUs around during later development. Could have been one of those 'time to migrate' issues I guess and possibly still conscious of speed on older CPUs? Not sure?

Last edited by gonegahgah on 16-May-2020 at 05:57 PM.
Last edited by gonegahgah on 16-May-2020 at 05:55 PM.

 Status: Offline
Profile     Report this post  
gonegahgah 
Re: Amiga Nowhere
Posted on 16-May-2020 18:07:50
#31 ]
Regular Member
Joined: 5-Dec-2008
Posts: 124
From: Australia

@NutsAboutAmiga

Quote:
Anyway, it be hell of job to keep the compiler up to date for all types of CPUs. and I guess this where bugger problem is.

The story was that it was quite easy to write a translater. They had a CPU isolation layer and a platform isolation layer and it was only these that had to be rewritten for a new CPU. That may have been something that Amiga Inc wanted to do at the time? It could have been like the issues with writing OpenOffice (or LibreOffice) for Amiga OS4.1 in that the OS was missing features.

One thing that I don't like is that VP has only a single byte to differentate differnt CPUs for native code. Who uses a byte for much at all in any day of recent?
Also, the Amiga taught me about removing limitations rather than imposing them (even though there were still some here and there of course!)

Quote:
Interpreter are easier but are slower, however token be optimized for optimal execution flow, that give huge befits over none optimized token organized more human readable pattern.

The Taos is more like a translater and does all the translation before running the code. It translates the VP program (with optional native tools if written) into the host CPU and platform.

Last edited by gonegahgah on 16-May-2020 at 06:13 PM.
Last edited by gonegahgah on 16-May-2020 at 06:12 PM.

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Amiga Nowhere
Posted on 16-May-2020 18:28:06
#32 ]
Elite Member
Joined: 9-Jun-2004
Posts: 11331
From: Norway

@gonegahgah

Quote:
and a platform isolation layer


I guess as start it might be a good idea using some standard thing like SDL, that way you support many operating system without having to actually support everything.

Last edited by NutsAboutAmiga on 16-May-2020 at 08:25 PM.
Last edited by NutsAboutAmiga on 16-May-2020 at 06:28 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
matthey 
Re: Amiga Nowhere
Posted on 16-May-2020 23:35:24
#33 ]
Cult Member
Joined: 14-Mar-2007
Posts: 677
From: Kansas

Quote:

gonegahgah wrote:
That is one of the nice things about VP that multiple arguments are returned in registers rather than having to pass a structure. VP will translate and use the stack if necessary but if there are enough registers it will just use them and it's all hidden from the coder.


Clever. Perhaps C doesn't support this in the hope of portable object files between different compilers. The architecture ABI usually only describes one return value (64 bit values can be in 2 registers on a 32 bit CPU though).

Quote:

I can see that they are trying to partially solve the problem but even that new C99 code still looks yucky to me.


I agree that the macro magic in the header file is yucky but not something the user needs to worry about. Include the header file and then simply use return(var1,var2,var3,var4). It is flexible and easy to use despite other concerns.

Quote:

They haven't done so in the VP files but I have wondered if it wouldn't be more efficient to get cos and sine at the same time? ie. qcall lib/getcossin,(iAngle: iCos,iSin). Wouldn't that speed some things up?


It is more efficient to calculate sin and cos at the same time. The 68k and x86 FPU had a FSINCOS instruction for that reason. The 68881 FSIN and FCOS are 391 cycles and FSINCOS is 451 cycles so calculating both at once is almost twice as fast. This is hardware but software calculations are often similar.

Why doesn't C have a sincos() function then? I expect it is because it was considered to be not common enough (gfx cards do the T&L today) and separate software calculations are considered to be fast enough. There are two return values which makes it messier in C but that hasn't stopped more common functions like div(), ldiv(), lldiv() which returns both the quotient and remainder in a structure. Note that the x86_64 (and the 68k) has instructions which return the quotient and remainder at the same time while the x86 FPU is deprecated. Some of the decisions for the C standard are based on politics and what is popular.

Quote:

VP is supposed to sort out endian problems at translation time so the code runs in correct endedness.
They have commands for dealing with unaligned data such as: cpy.ni [pStorage], iValue
Their longs and doubles only unalign down to 4 byte bounderies but there are ways around that.


The default alignment should depend on the target. While natural alignment usually provides the best performance, it also wastes memory with padding and programs become slower as they get bigger.

Quote:

That's an interesting thought. I was surprised that Tao were still developing in 32bit with all the 64bit CPUs around during later development. Could have been one of those 'time to migrate' issues I guess and possibly still conscious of speed on older CPUs? Not sure?


It is easier to write portable code with advances in the languages and programmers are more experienced at it. It is still tricky in some areas, more work, difficult to produce optimal code on a wide variety of targets and needs testing on a wide variety of targets. Code that works well on 32 bit and 64 bit CPUs may fail miserably on a 16 bit embedded CPU. Many programmers today are assuming the target is at least a 32 bit little endian CPU.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Amiga Nowhere
Posted on 17-May-2020 16:50:53
#34 ]
Elite Member
Joined: 6-May-2007
Posts: 9855
From: Greensborough, Australia

@gonegahgah

Quote:
It didn't have shared libraries per se but instead everything was a tool.


That would explain it.

Quote:
One thing I especially like is that functions can return multiple results.I can remember having to pass structures in C which I find extremely ugly.Not sure how that has advanced in this day and age or if it is still a problem?


It's still a problem to my knowledge and after a cursory search nothing has change. That would mean Amiga E has that superiority over C. The common workaround would be to pass a structure to store them in, like you did, or pass a pointer to a parameter to store the result back in. I favour the latter as it looks more neat and doesn't require extra junk for storage. Of course the best way would be to simply return multiple values but it was never part of the C standard that I know of.

Quote:
They did something strange in that they embedded the tool name in the tool itself.You couldn't just move it somewhere else without another tool (The Amiga Inc. mob wrote one).If the embedded toolname didn't match the tool path then it was invalid.


Amiga libraries and devices have that problem as well. If you wanted to rename the resource file. It didn't work as the name was stored in the binary itself.

Quote:
Their object model didn't include being able to make methods as tools.


How ironic.

Quote:
Haiku Raggae copied Amiga datatypes and had a slightly better solution...


The solution to datatypes looking like an OOP hack into a C interface?

 Status: Offline
Profile     Report this post  
gonegahgah 
Re: Amiga Nowhere
Posted on 17-May-2020 22:29:53
#35 ]
Regular Member
Joined: 5-Dec-2008
Posts: 124
From: Australia

@Hypex

Quote:
That would mean Amiga E has that superiority over C.

Wow! Good on Wouter van Oortmerssen for having that. I've been reading a bit more about him lately.
He wrote a lot of his own programming languages and he was the fellow working on the programming language Sheep.
I wonder if it was supposed to have multiple argument returns too?

Quote:
Amiga libraries and devices have that problem as well. If you wanted to rename the resource file. It didn't work as the name was stored in the binary itself.

Ah, that's interesting. I didn't recall that. Why was it done that way?
I'm wanting to treat the whole Tao 'file system' as a library anyway which is why it doesn't worry me.

Quote:
The solution to datatypes looking like an OOP hack into a C interface?

The Tao system includes virtual tools that only load when first needed.
Otherwise a tool not marked as virtual is loaded at the same time the calling tool is.
The virtual tools seem like a better opportunity to me, if tied into an object model, for optional methods...

Last edited by gonegahgah on 17-May-2020 at 11:11 PM.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Amiga Nowhere
Posted on 18-May-2020 17:46:13
#36 ]
Elite Member
Joined: 6-May-2007
Posts: 9855
From: Greensborough, Australia

@amigadave

Quote:
Will there be, or can there ever be, a version of UAE that takes advantage of multiple cores/cpus/threads?


Just going back and touching on this. It's hard to divide UAE up I think. It's emulating a computer that does one thing at once CPU wise. But also, the clock is shared between chipset and CPU, so you've got to simulate multiple operations that run by the book. Or clock in this case. UAE would work in the general way a line emulator does. That is, simulating the hardware screen line by line. So the emulator knows how many clock cycles will take up one line of screen. It will emulate CPU code up to that amount, then render the screen line, converting the bitmap and adding any sprites. Sound also, though this is slower, going by the line. Those operations would have to be split up somehow. Then things like JIT need to be taken into account. And RTG as well which speeds it up and takes a load off.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Amiga Nowhere
Posted on 18-May-2020 18:13:07
#37 ]
Elite Member
Joined: 6-May-2007
Posts: 9855
From: Greensborough, Australia

@gonegahgah

Quote:
Wow! Good on Wouter van Oortmerssen for having that. I've been reading a bit more about him lately.


Yes, it returns it in registers as you would expect, though that would be hidden.

Quote:
He wrote a lot of his own programming languages and he was the fellow working on the programming language Sheep.I wonder if it was supposed to have multiple argument returns too?


I remember the language of the Sheeple. So many Amiga projects we saw but disappear. I don't know but I'm sure Wouter would have thought about it.

Quote:
Ah, that's interesting. I didn't recall that. Why was it done that way?


Because in the binary there would be the library name that would be checked against, along with version, found in the resident structure. So really the file name matches the library. But they need to match as, when it gets loaded off disk in the csse it isn't in memory, the OS will look for a library file exactly matching the library name.

Quote:
I'm wanting to treat the whole Tao 'file system' as a library anyway which is why it doesn't worry me.


For some reason I see Tao and think about a Guru meditating. It had to have some link to the Amiga.

Quote:
The Tao system includes virtual tools that only load when first needed.Otherwise a tool not marked as virtual is loaded at the same time the calling tool is.The virtual tools seem like a better opportunity to me, if tied into an object model, for optional methods...


Sounds like a good idea. Seems neater that datatypes. I've had this gripe against datatypes. Before I understood what OOP and E helped me to know about it, I thought the datatypes API just looked like a mess. It had these strangely named functions like New doing things like an Open. New in Amiga terms used to be a replacement function. Then there was this variable message thing used, that wasn't in a usual structure, nor a tag list. After I learnt what OOP was about, I could see what they were trying to do, but I wondered why. They were using C to do sometihng C++ was meant for and to me it just looked like a mess. If they wanted to AmigaOS to become OOP why not just jump to C++? Or ahem, ObjC? I think it would have been better to hide the mess in macros if they insisted on hacking it in. Even on OS4, where they customised compiler library calls to work like a method by hiding the self pointer parameter, wasn't updated ot use the mehod calls. Would have been a good oppertunity for some datatype objects that really looked like objects. Being able to call methods off a class pointer and oganising it to what type of data it was.

 Status: Offline
Profile     Report this post  
bison 
Re: Amiga Nowhere
Posted on 18-May-2020 18:25:30
#38 ]
Super Member
Joined: 18-Dec-2007
Posts: 1577
From: N-Space

@Hypex

Quote:
Or ahem, ObjC?

The window is on that is probably closed, but that would have been an interesting development.

_________________
"Unix is supposed to fix that." -- Jay Miner

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Amiga Nowhere
Posted on 18-May-2020 18:56:03
#39 ]
Elite Member
Joined: 9-Jun-2004
Posts: 11331
From: Norway

@Hypex

From the sound of it, it sounds like UAE is busy looping.

I guess, it might possible speed things up, if its possible to wake up tasks (emulated chips) based on some kind action, so they not running all the time, but instead awaken when needed.

Last edited by NutsAboutAmiga on 18-May-2020 at 06:59 PM.
Last edited by NutsAboutAmiga on 18-May-2020 at 06:58 PM.
Last edited by NutsAboutAmiga on 18-May-2020 at 06:58 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Amiga Nowhere
Posted on 18-May-2020 20:33:55
#40 ]
Elite Member
Joined: 9-Jun-2004
Posts: 11331
From: Norway

@Hypex

you can't just jump to C++, as you need to support older programes as well,
but i wonder if not ideltool can generate struct with virtual metodes,
if they compatible function pointer idea, I have not looked at that deeply.

I tried to compiled .library with g++, Im not sure if was some messed up or if the symbols where not found, it might be possible, or might be possible with just tiny bit more work.

Anyway idltool is too sloppy it does not follow the more strict c++ rules, I had to do lot casting of function pointers to make it compile.

Last edited by NutsAboutAmiga on 18-May-2020 at 08:35 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle